ASE1502_OptimizationCriteria_v1_0

7/27/2019 ASE1502_OptimizationCriteria_v1_0

http://slidepdf.com/reader/full/ase1502optimizationcriteriav10 1/20

ChangestoscopeandsemanticsChangestoscopeandsemanticsChangestoscopeandsemanticsChangestoscopeandsemanticsofsessionofsessionofsessionofsession----leveloptimizatleveloptimizatleveloptimizatleveloptimizationsettingsionsettingsionsettingsionsettingsinASE15.0.2inASE15.0.2inASE15.0.2inASE15.0.2

TECHNICAL WHITE PAPER



Changes to scope and semantics of session-level optimization settings in ASE 15.0.2

Version 1.0 – February 20082

Contents

Summary..................................................................................................................3 Who should read this whitepaper? .............................................................................4 The concept of optimization goals in ASE 15...............................................................5

Optimization goals vs. Optimization criteria ....................................................................... 6 Why optimization goals are important in ASE 15 ................................................................ 6 So, how do optimization goals really work? ....................................................................... 7

Overview of changes to session-level optimization settings ..........................................8 Scope and Semantics in ASE pre-15.0.2............................................................................ 8

Guaranteeing optimization goals for procedures in pre-15.0.2 .........................................................9 Session-level optimization criteria settings in pre-15.0.2 ...............................................................10

Scope and Semantics in 15.0.2 ESD#2.............................................................................11 Guaranteeing optimization goals for procedures in 15.0.2 ESD#2..................................................12 Session-level optimization criteria settings in 15.0.2 ESD#2..........................................................12

Scope and Semantics in ASE 15.0.2 .................................................................................13 Scope and Semantics in ASE 15.0.2 ESD#1......................................................................14

Determining the current optimization goal setting .....................................................15 Peculiarities around to watch out for................................................................................16 Determining the current optimization criteria settings........................................................17

Exportability of session-level optimization settings ....................................................18 Introducing the 'set export_options' command .................................................................18 Exporting optimization settings........................................................................................18

Author Rob VerschoorEvangelism Group, Sybase EngineeringSybase, Inc.

Revision History Version 1.0 - February 2008





Summary'Optimization goals' are a central concept of the new query processing engine in ASE 15, as they controlthe possible query plans that the query optimizer may consider for a query. Therefore, the choice of optimization goal can make a major difference for the performance of a query.The scope and semantics of specifying session-level settings for optimization goals (as well as for theunderlying 'optimization criteria') have undergone some changes in ASE versions 15.0.2, 15.0.2 ESD#1

and 15.0.2 ESD#2, as described in this document.The main recommendations are:

• Avoid using excessive session-level optimization settings if possible since this increases thecomplexity of your SQL code

• When using session-level optimization settings, upgrade to ASE 15.0.2 ESD#2 or later since the

session-level optimization settings are more intuitive and easier to use than in earlier ASE 15versions.

• When using session-level optimization settings in stored procedures, explicitly set theoptimization goal as the first statement in the procedure.





Who should read this whitepaper?If you are not using session-level settings for optimization goals or optimization criteria, then you neednot pay attention to the rest of this whitepaper. Otherwise, please read on, since the changes to scopeand semantics in ASE 15.0.2 and later could potentially impact the performance of specifically tunedqueries or stored procedures in your system.If you're not sure what "session-level settings for optimization goals or optimization criteria" are, please

refer to pages 5 - 6 where these concepts are explained.

Note that session-level optimization goal settings, and certainly session-level settings for individualoptimization criteria, quickly gets you into the territory of advanced performance fine-tuning. Thereforethese topics may not be for everyone.

Also note that the scope and semantics of server-level and query-level settings for optimization goals and

optimization criteria have not changed in any ASE 15 version. This document is specifically about session-level settings for optimization goals and optimization criteria.





The concept of optimization goals in ASE 15 A central concept of ASE 15’s new query processing engine is the 'optimization goal'. In essence, this canbe seen as a hint to the ASE query optimizer, providing an indication of the nature of the query beingoptimized.To illustrate the underlying idea, a typical OLTP query and a typical DSS query will normally end up withvery different query plans due to the different data access patterns used by these queries: OLTP tends to

hit one or just very few rows, and join only a few well-indexed tables; DSS typically hits many rows butreturns just a few, and can join a large number of tables.Because of their different access patterns, OLTP queries will often run best when they use a classicnested-loop join whereas a DSS query is more likely to run faster with a merge join or a hash join. Byindicating that a query is for OLTP or DSS purposes, the optimizer may save itself a lot of work (time,memory, CPU) when generating a query plan.

ASE 15 provides three optimization goals (ordered from 'narrow' to 'wide', corresponding to the numberof options and strategies they allow the optimizer to consider):

• allrows_oltp (best for OLTP queries)• allrows_mix (default after upgrading to ASE 15)• allrows_dss (best for DSS queries)

The different optimization goals have the following effect on the ASE query optimizer:

• allrows_oltp offers the narrowest selection of join methods: the query optimizer is allowed to

consider nested-loop joins only

• allrows_mix allows also merge joins to be considered by the optimizer, as well as parallel plans

(if the ASE server is configured for parallelism).

• allrows_dss offers the widest selection of join methods: also hash joins may be considered bythe optimizer

For allrows_mix and allrows_dss, additional low-level processing algorithms are enabled which aredisabled for allrows_oltp.

It should be noted that when the optimization goal is widened, the query optimizer might use significantlymore resources (time and procedure cache) to generate a query plan.If the optimizer generates the same query plan, with only nested-loop joins, under allrows_dss and

allrows_oltp, you should expect the optimization under allrows_dss to take more time and procedurecache than under allrows_oltp.

The optimization goal can be defined on the level of the ASE server, session or individual query:

-- server-wide default:

sp_configure 'optimization goal', 0, 'allrows_dss'

-- session-level setting (overrides server-wide setting):

set plan optgoal allrows_dss

-- query-level setting (overrides server-wide and session-level

settings):

select * from T1, T2 where T1.a = T2.b

plan '(use optgoal allrows_dss)'





Optimization goals vs. Optimization criteria

An optimization goal is actually a collection of on/off settings for a series of properties known as'optimization criteria'. Individually, an optimization criterium allows (when it is enabled) or disallows(when disabled) the optimizer to consider a particular algorithm (as for access methods, for joins, for

grouping, sorting, etc.).Some examples of optimization criteria are:

set hash_join on -- enables hash joins

set store_index off -- disables reformatting

Note that Sybase does not recommend using explicit settings for optimization criteria unless advised bySybase Technical Support. Sybase recommends using optimization goals instead.

Session-level settings for optimization criteria are covered in this document for completeness.

When specifying a session-level setting for an optimization criterium, it is important to observe how thismay interfere with optimization goal settings. Since an optimization goal is a collection of optimizationcriteria, setting a session-level optimization goal overrides any previous settings.

The following examples show how reversing the order of to 'set' statements can produce a different endresult:

set plan optgoal allrows_mix -- allow merge joins and

-- nested-loop joins

set merge_join off -- disallow merge joins

go

Result: merge joins are disabled; only nested-loop joins may be considered by the query optimizer

set merge_join off -- disallow merge joins

set plan optgoal allrows_mix -- allow merge joins and

-- nested-loop joins

go Result: both merge joins and nested-loop joins may be considered by the query optimizer

Why optimization goals are important in ASE 15

It is important to understand ASE 15's optimization goals because they can have a major impact on queryperformance. This is because each optimization goal allows or disallows certain join types to be used.

For example, for DSS-type queries, hash joins often result in significantly better response times thannested-loop joins. In order to get maximum benefit from ASE 15's capabilities, a DSS application shouldtherefore use allrows_dss as the optimization goal, since this allows the optimizer to consider hash joins.One of the first choices to be made in ASE 15 is therefore which server-wide optimization goal to use. Inaddition, it may be beneficial to override the server-wide setting for specific sessions that appear to run

more efficiently with a different optimization goal.

A specific aspect of optimization goals applies to stored procedures. Stored procedures are typicallydeployed as self-contained units, whose query plans have been tuned for best performance. In ASE 15,'best performance' implies that a procedure is optimized with the optimization goal that allows the





optimizer to pick the best-performing plan. In other words, for stored procedure performance to bereliable, it is important to guarantee that a procedure is optimized with a particular optimization goal.

Against this background, it is also important to understand the changes to session-level optimizationsemantics.

This document does not cover the process of determining which optimization goal is best for a mixed-workload system, but describes the semantics, and the changes made to these semantics, of specifying

session-level settings for the optimization goal.Understanding these semantics is essential if you are using session-level optimization goal settings.

So, how do optimization goals really work?

ASE 15 users who looked into optimization goals and optimization criteria in more detail, often discoveredthat the scope of session-level optimization goal settings were not behaving as they expected. As anexample, let’s take the following SQL batch:


<select-statement-1>

set plan optgoal allrows_oltp

<select-statement-2>

go

Most ASE users would probably expect that select-statement-1 gets optimized with allrows_dss whileselect-statement-2 is optimized with allrows_oltp. However, prior to 15.0.2 this was not how it

worked -- though as of 15.0.2 ESD#2, it does indeed work this way.The following sections describe the precise scope and semantics in the different ASE 15 versions.

NB: all code examples in this document assume that the ASE statement cache is disabled (run setstatement_cache off first, if in doubt).





Overview of changes to session-level optimizationsettingsIn a nutshell, the changes in scope and semantics of session-level settings for optimization goals and

optimization criteria are as follows:

• Prior to 15.0.2 (i.e. until 15.0.1 ESD#3), session-level settings for optimization goals and

optimization criteria take effect only in the next batch, stored procedure call, or execute-immediate.

• As of 15.0.2 ESD#2, session-level settings for optimization goals and optimization criteria takeeffect on the next statement in the batch or the stored procedure. This is how most ASE users

would intuitively expect these settings to work.

• In 15.0.2 and 15.0.2 ESD#1, the behaviour of session-level settings for optimization goals and

optimization criteria is a mix of the above. As a result, the exact impact on query compilationmay be hard to understand in some complex cases.If you are currently running ASE versions 15.0.2 or 15.0.2 ESD#1, and you are using session-

level optimization settings, Sybase recommends upgrading to 15.0.2 ESD#2 or later. Please

review the rest of this document to asses the potential impact of this upgrade on your queryplans.

The details for each specific ASE version are described below.

Scope and Semantics in ASE pre-15.0.2

In ASE 15.0 prior to 15.0.2 (i.e. from 15.0 GA until 15.0.1 ESD#3), session-level settings for optimizationgoals and optimization criteria take effect only in the next batch, stored procedure call, or execute-

immediate. Other statements in the same batch or procedure in which the session-level settings arechanged, are not affected by these settings.

• In example A below, statements 1, 2 and 4 (lines 3, 5 and 8, respectively) will be optimized with

allrows_dss since that's what the optimization goal is set to (due to line 1) at the start of thebatch (line 3) in which these statements appear.

In pre-15.0.2, the set plan optgoal statements in this batch (on lines 4 and 7) do not affect thealready-started compilation of the statements in the batch itself (i.e. those on lines 3, 5 and 8),but only of statements whose compilation is initiated from that point onwards, such as the nextbatch (line 11), or subsequent execute-immediate statements (line 6) or stored procedure calls(line 9).

• Next, statement 3 (on line 6) is optimized only once execution reached line 6 since it is wrappedin an execute-immediate call. On line 6, the optimization goal is set to allrows_mix (as a result

of line 4), and statement 3 is therefore optimized with allrows_mix.

• By the time stored procedure 'p' is executed on line 9, the optimization goal is set to

allrows_oltp (as a result of line 7), so this is used for optimizing 'p'.

• Lastly, statement 5 (on line 11) starts a new batch, and this batch is optimized with the

optimization goal set at that point, which is allrows_oltp (as a result of line 7).





Example A: ASE pre-15.0.2

1 set plan optgoal allrows_dss

2 go

3 <statement-1> -- optimized with allrows_dss

4 set plan optgoal allrows_mix


6 exec('<statement-3>') -- optimized with allrows_mix7 set plan optgoal allrows_oltp


9 exec p with recompile -- optimized with allrows_oltp

10 go

11 <statement-5> -- optimized with allrows_oltp

12 go

For a stored procedure, the scope of an optimization goal is similar to a batch:

• Statements 6 and 8 in procedure 'p2' (on lines 16 and 20) are optimized with allrows_mix sincethat optimization goal is in force at the moment when the procedure is first executed (as a result

of line 22).Like in batches, in pre-15.0.2 any set plan optgoal statements inside the procedure do nothave affect compilation of statements inside the stored proc itself since compilation has alreadystarted at that point.

• However, again like the batch above, they do affect statements that will be compiled from that

point onwards. Therefore, procedure 'p' (line 18) will be optimized with allrows_dss (as a resultof line 17), and so will statement 7 (line 19).

13 create procedure p2

14 as

15 set plan optgoal allrows_oltp

16 <statement-6> -- optimized with allrows_mix

17 set plan optgoal allrows_dss18 exec p with recompile -- optimized with allrows_dss

19 exec('<statement-7>') -- optimized with allrows_dss


21 go


23 go

24 exec p2 -- optimized with allrows_mix

25 go

Note that the optimization goal setting at the moment when a stored procedure is created, is irrelevant:it's the execution time that matters (this applies to all ASE 15 versions).

Guaranteeing optimization goals for procedures in pre-15.0.2

As explained earlier, it is important to guarantee that a stored procedure is always optimized with theoptimization goal that allows the best query plan.





In pre-15.0.2 it is unfortunately not easy to provide such a guarantee, since -as shown in example A above- putting a set plan optgoal statement in the procedure itself has no effect on the regular

statements inside the procedure.Therefore, the best way to achieve this for a procedure 'p3' is as follows:

• Rename procedure 'p3', for example to 'p3_a'• Create another stored procedure, named 'p3', with the exact same parameters as the original

procedure, now renamed 'p3_a'.•

Assuming p3 should always be optimized with optimization goal allrows_xxx the body of p3should look like this:

create proc p3 @param_1 int, @param_2 int, …etc…

as

set plan optgoal allrows_xxx

exec p3_a @param_1, @param-2, …etc…

It is recommended to put set plan optgoal allrows_xxx as the first statement in the body of procedure 'p3_a' as well, so as to cover execute-immediate statements.

Note that this approach has some drawbacks:• The nesting level is increased, which may be undesirable.

• If the stored proc 'p3_a' ever gets its plan recompiled due to -for example- update statistics or

schema changes, it may be compiled with a different optimization goal, namely the activesession-level optimization goal or, if not set, the server-wide optimization goal. This cannot becontrolled in pre-15.0.2.

Session-level optimization criteria settings in pre-15.0.2

In ASE pre-15.0.2, the scope of individual session-level optimization criteria settings (set hash_join off,set store_index off, etc) is identical to that of set plan optgoal, as explained above.If it is required to stop reformatting for a specific statement only (either in batch or stored procedure),either of the following options can be used. Since there is no functional difference, which of these optionsis used is perhaps a matter of taste.

The first option is to wrap the statement in execute-immediate and disable the optimization criteriumdirectly before it:

[…]

<statement-1> -- reformatting may occur

set store_index off

exec('<statement-2>') -- reformatting will not occur

set store_index on


[…]

The second possibility is to specify the optimization criterium in the abstract plan clause for the specificquery (obviously, this is not a session-level setting as discussed in this document):

select * from mytable, yourtable where…

plan '(use store_index off)'





Scope and Semantics in 15.0.2 ESD#2

In version 15.0.2, some aspects of session-level optimization settings were changed to make thesefeatures more intuitive and easier to use. In short, session-level settings for optimization goals andoptimization criteria take immediate effect on the next statement in the batch or procedure.

This is illustrated in example B below (the statements in this example are identical to those in example A for pre-15.0.2).

• Statement 1 (on line 3) will be optimized with allrows_dss since that's what the optimizationgoal is set to (due to line 1) at that point. Note that, as far as statement 1 is concerned, this isidentical to pre-15.0.2 (but different from 15.02/15.0.2 ESD#1).

• Statement 2 (on line 5) will be optimized with allrows_mix since line 4 has changed theoptimization goal setting. Likewise, statement 3 (on line 6) is also optimized with allrows_mix.

• Statement 4 (on line 8) will be optimized with allrows_oltp since line 7 has changed theoptimization goal setting. This also applies to the stored procedure 'p' on line 9.

• Statement 5 (line 11) will be optimized with allrows_oltp since no changes to the optimizationgoal setting have been made since line 7.

Example B: ASE 15.0.2 ESD#2


2 go




6 exec('<statement-3>') -- optimized with allrows_mix




10 go


12 go

For a stored procedure, the semantics are identical:

• Statement 6 (on line 16) will be optimized with allrows_oltp since that optimization goal has

been on the preceding line. Note that the setting on line 15 overrides that on line 22: the lastoptimization goal setting in the execution sequence applies.

• The stored procedure 'p' (line 18) and statements 7 and 8 (lines 19 and 20) are optimized withallrows_dss since line 17 has set this optimization goal.

• Note that no statements in 'p2' are optimized with allrows_mix, despite the fact that line 22causes the procedure to initially be optimized with allrows_mix. This is because inside 'p2', thefirst optimizable statement (line 16) is preceded by a change of the optimization goal setting (line15), so at that point the allrows_mix setting from line 22 no longer applies. If line 15 had beenpreceded by another optimizable statement, then that statement would have been optimized with





allrows_mix in the exact code example below (note however the remark about recompilationon page 12).


14 as




18 exec p with recompile -- optimized with allrows_dss19 exec('<statement-7>') -- optimized with allrows_dss


21 go


23 go

24 exec p2 -- p2 is optimized with allrows_mix

25 go -- but this can be overridden in the

-- body of p2 itself

Guaranteeing optimization goals for procedures in 15.0.2 ESD#2

In 15.0.2 ESD#2, it has become quite simple to guarantee that a stored procedure is always optimizedwith a particular optimization goal. All that is required is to put set plan optgoal allrows_xxx as thefirst statement in the body of the stored procedure.The disadvantage is that this still requires a change to the stored procedure code, but things have

become much simpler compared with pre-15.0.2.

The recommendation to set the optimization goal as the first statement in the procedure helps to avoid

an unpredictable situation that may occur when the procedure gets its plan recompiled (which can alwayshappen due to update statistics or schema changes, for example). In example B above, anyoptimizable statements prior to line 15 would be optimized with the active session-level optimization goal

at the moment of recompilation, or when that is not set, with the server-wide optimization goal. Sincethis optimization goal may not be allrows_mix as shown above, this may lead to a different query planthan expected.

Session-level optimization criteria settings in 15.0.2 ESD#2

In ASE 15.0.2 ESD#2, session-level optimization criteria settings (set hash_join off, set store_index off,etc) also take immediate effect on the next statement.

For example, to stop reformatting for one specific statement only (either in batch or stored procedure),the following can be used. Note that it is no longer needed, as in pre-15.0.2, to wrap statement 2 in anexecute-immediate:


[…]


set store_index off

<statement-2> -- reformatting will not occur

set store_index on


[…]





It is of course still possible to use the query-specific abstract plan notation as shown in the pre-15.0.2examples.

Scope and Semantics in ASE 15.0.2

In version 15.0.2, some aspects of the scope of session-level optimization settings for have changed frompre-15.0.2. Unfortunately, the precise impact on query optimization may sometimes be difficult to

understand.Note that the 15.0.2 behaviour described below has been changed in 15.0.2 ESD#2 to be more intuitiveand easier to use. If you are using session-level optimization settings, Sybase recommends upgrading to15.0.2 ESD#2 or later.

For batches, all set plan optgoal statements are pre-evaluated when the batch is first parsed in orderto determine the resulting optimization goal at the end of the batch. This optimization goal is thenapplied to the batch itself for query optimization.In example C below, this means that the resulting optimization goal at the end of the batch (line 10) isallrows_oltp, due to the last set plan optgoal statement in the batch (line 7). Therefore,allrows_oltp is what all optimizable statements in the batch (on lines 3, 5 and 8) are then compiledwith.

As in pre-15.0.2, execute-immediate statements and stored procedure calls are optimized with theoptimization goal that is in force at the moment when they are executed (actually, when they'reoptimized). As a result, statement 3 (line 6) is optimized with allrows_mix and procedure 'p' (line 9) is

optimized with allrows_oltp.The next batch (at line 11) is also optimized with allrows_oltp.

Example C: ASE 15.0.2


2 go




6 exec('<statement-3>') -- optimized with allrows_mix




10 go


12 go

For a stored procedure, optimization goal settings behave the same as in pre-15.0.2:


14 as

15 set plan optgoal allrows_oltp16 <statement-6> -- optimized with allrows_mix


18 exec p with recompile -- optimized with allrows_dss

19 exec('<statement-7>') -- optimized with allrows_dss






Determining the current optimization goal settingWhen engaged in performance tuning, it is likely you may need to determine what optimization goal isset at a particular point during execution. One's first attempt will probably to try query @@optgoal.However, this does not function as expected. Try running the following:


select @@optgoal -- shows allrows_oltp

set plan optgoal allrows_mix




go

You will see that @@optgoal returns the same value for all three select statements (exactly which valueis reported can vary in different ASE versions; shown above are the values in 15.0.2 or later). This effectis caused by the way global variables are evaluated by ASE.The right way to determine the current optimization goal is to wrap the select in execute-immediate:


exec ('select @@optgoal') -- shows allrows_dss


exec ('select @@optgoal') -- shows allrows_mix


exec ('select @@optgoal') -- shows allrows_oltp

go

This will correctly return the current optimization goal setting, both in batches and in stored procedures.This works in all versions of ASE 15.

In cases where it is not possible to use execute-immediate, for example when execute-immediate wasalready used on a higher nesting level, the current optimization goal setting can also be determined byquerying the virtual table master..sysoptions. This requires ASE 15.0.2 or later:


select currentsetting from master..sysoptions

where name = "optgoal" and spid = @@spid







go

Instead of querying sysoptions directly, the system stored procedure sp_options can also be used(sp_options reads sysoptions).





Peculiarities around to watch out for

When using the queries described above to determine a session's current optimization settings, please beaware of the following.While select @@optgoal, when run from within execute-immediate, provides an immediate reflection of the changes made to the session-level optimization goal in a batch or stored procedure, there is one

aspect that can be confusing.This is best illustrated by the following example:


2 go

3 exec ('select @@optgoal') -- shows allrows_oltp


5 exec ('select @@optgoal') -- shows allrows_dss


7 exec ('select @@optgoal') -- shows allrows_oltp

8 go

The first select of @@optgoal (on line 3) does not show the optimization goal in force at that moment,which is allrows_mix. Due to the way @@optgoal is evaluated by ASE's query processing engine, thisshows the optimization goal setting resulting from line 6. Once the optimization goal is changed in the

batch, like on line 4, that change will be reflected correctly on line 5.

Unfortunately, the situation in a stored procedure is slightly different:

1 create proc p

2 as

3 exec ('select @@optgoal') -- shows ?


5 exec ('select @@optgoal') -- shows allrows_dss

6 go


8 go

9 exec p [ with recompile ]10 go

The select on line 3 may show allrows_mix or allrows_dss, depending on the exact ASE version anddepending on how the procedure is executed. When executing the procedure with recompile, line 3shows allrows_dss, even though the actual optimization goal used by the optimizer on line 3 may bedifferent (namely, the active session-level optimization goal at the moment of recompilation).When the procedure is executed without recompile (i.e. when a plan already exists), line 3 shows theactive session-level optimization goal at the moment of execution although a statement at line 3 of theprocedure's existing plan may have been generated under a different optimization goal.

Recommendation:

To avoid confusion, when using different session-level settings for the optimization goal in a batch or

procedure, it is recommended to set the optimization goal as the first statement in the batch orprocedure.

Similar as described above for optimization goals, this section also applies when setting session-level

optimization criteria.





Determining the current optimization criteria settings

Similar to the previous section, it may be required to determine the session's current settings foroptimization criteria. This can also be done by querying sysoptions.For example, to determine the current setting for store_index (which controls whether reformatting may

be considered by the optimizer) in the current session, use this query:

select currentsetting from master..sysoptionswhere name = "store_index" and spid = @@spid

This will return either 0 (=disabled) or 1 (=enabled).

Instead of querying sysoptions directly, the system stored procedure sp_options can also be used.

In pre-15.0.2, sysoptions does not exist. If you are running 15.0.1 or later, the current session-levelsettings for optimization criteria can also be determined by enabling the diagnostics option with commandset option show_search_engine long. For every query against a table (i.e. not for queries like select1), the optimizer will then print a stream of diagnostics. Among other things, this contains a line startingwith "OptCriteria:", listing the optimization criteria that are currently enabled:

[…]

OptCriteria: distinct_sorted distinct_sorting distinct_hashing

group_sorted group_hashing order_sorting nl_join

append_union_all merge_union_all merge_union_distinct

hash_union_distinct store_index index_union streaming_sort

nary_nl_join opportunistic_distinct_view replicated_partition

Optimization Goal: allrows_mix

[…]

Note that the optimization goal and optimization criteria resulting from set option

show_search_engine long are always accurately reflected, so they do not suffer from the peculiaritiesdescribed on page 14.

By default, the diagnostics from set option […] are sent to the ASE console. In order to receive them atthe client, traceflag 3604 must be enabled.

Note that the amount of output generated by this diagnostics command can be significant.





Exportability of session-level optimization settingsWhen discussing session-level settings for optimization goals and optimization criteria, the aspect of 'exportability' should not remain unmentioned.

Introducing the 'set export_options' command

In ASE 12.5.4 and ASE 15.0.2, a new command set export_options on was introduced in ASE. This

command has the effect of 'exporting' session-level settings from a stored procedure or an execute-immediate statement to its caller. This effect applies to most session-level 'set' options, although thereare some version-specific special cases around optimization settings.Here is a general example. When running set rowcount in a stored procedure, this has no effect on therowcount setting in the caller. This is how ASE has always behaved and this is still the default today:

-- we're assuming my_table has 10 rows!

select * from my_table -- returns 10 rows

go

create procedure p

as

set rowcount 3

select * from my_table

goexec p -- returns 3 rows

go


go

When including set export_options on in the procedure, the rowcount limitation will also apply to thecaller:

-- we're assuming my_table has 10 rows!


go

create procedure p

asset rowcount 3

select * from my_table

set export_options on -- can occur anywhere in the proc

go

exec p -- returns 3 rows

go


go

For login triggers, set export_options is implicitly enabled. It can be disabled by including thecommand set export_options off in the login trigger.

Exporting optimization settings When it comes to session-level settings for optimization goals and optimization criteria, things behave asdescribed above, provided you're running ASE 15.0.2 ESD#2 or later.





In ASE 15 versions prior to 15.0.2 ESD#2, any session-level settings for optimization goals andoptimization criteria were always global for the entire session. This implied that when an optimization

goal setting was changed inside a stored procedure, the change was effective for the entire session fromthat point onwards.





Sybase, Inc.Worldwide Headquarters

One Sybase DriveDublin, CA 94568-7902 USA Tel: +800 8 SYBASE

www.sybase.com

Copyright © 2008 Sybase, Inc. All rights reserved. Unpublished rights reserved under U.S. copyright laws. Sybase and the Sybase logo are trademarks

of Sybase, Inc. All other trademarks are property of their respective owners. ® indicates registration in the United States. Specifications are subject tochange without notice.

ASE1502_OptimizationCriteria_v1_0

Documents

Transcript of ASE1502_OptimizationCriteria_v1_0