oracle cost based optimizer (cbo) and its optimism about cardinalities%3a typical problem situations

The CBO and its Optimism about CardinalitiesTypical Problem Situations

Martin Frauendorfer, SAP Active Global Support

[email protected]

December 2008

© SAP 2007 /

1. Introduction2. The correlation problem3. The STAR transformation problem4. Some other typical problems5. Appendix

Agenda

© SAP 2007 /

Introduction

What is meant with “Cardinality”?

The Oracle Cost Based Optimizer calculates both costs („Estimatedcosts“) and cardinality („Estimated rows“). The cardinality indicates thenumber of records the CBO expects in each step of the execution plan.Example:

--------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

--------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 245 | 735 | 67 (3)| 00:00:01 |

|* 1 | TABLE ACCESS FULL| AAA | 245 | 735 | 66 (2)| 00:00:01 |

--------------------------------------------------------------------------

The cardinality is closely related to the selectivity (that defines thefraction of records that fulfill the specified condition(s)):

Cardinality = Total records * selectivity

Cardinality Costs

© SAP 2007 /

Introduction

Why do we care for the cardinality – isn’t it enough to check the costs?

For simple single table accesses it is usually sufficient to understand thecost calculation. It is often not necessary to have a closer look at theestimated number of records returned.For complex queries where several or many tables are joined a propercardinality estimation is very important because often the following ruleapplies:

Lower cardinality Table more at the beginning of the join sequence

This means that a wrong assumption about cardinalities can significantlyimpact the join sequence and the access performance.Real life examples showed a performance degradation of factor 100 andmore that were finally caused by a low cardinality estimation and a wrongjoin order!

© SAP 2007 /

Introduction

How can the estimated cardinality be compared with the real cardinality?

It‘s easy to retrieve the estimated cardinality from the execution plan, butit can be hard to determine the real number of returned rows.If you don‘t want to count the records for each step of the execution planmanually by starting count operations on the database you can considergathering plan statistics.The following two alternatives exist to activate plan statistics

/*+ GATHER_PLAN_STATISTICS */ hint (Oracle >= 10g)ALTER SESSION SET STATISTICS_LEVEL = ALL;

The plan statistics will be written into V$SQL_PLAN_STATISTICS_ALLand contain information for each step of the execution plan like:

Time of each stepDisk reads of each stepBuffer gets of each stepRecords per step

The records per step are the real cardinalities that can now be comparedto the „estimated rows“ of the CBO.

© SAP 2007 /

Introduction

Real life example:

In the following document you can find a typical real life example thatshows how cardinality misconceptions of the CBO can massively impactthe join order and performance:

Example

With a better cardinality estimation the CBO was able to find an executionplan that ran more than 1000 times faster. The number of buffer gets perexecution was reduced by more than factor 2000.

https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/b0cdbede-27af-2b10-0e9f-b32ad0a9597f

© SAP 2007 /

The Correlation Problem

What is the correlation problem?

Per default the CBO assumes that conditions on different columns are notcorrelated. In reality column values can be extremely correlated.Example:

Column X has 3 values: 1, 2, 3Column Y has 5 values: 1, 2, 3, 4, 5The CBO expects that all combinations of these two columns exist:(1, 1), (1, 2), (1, 3), (1, 4), (1, 5)(2, 1), (2, 2), (2, 3), (2, 4), (2, 5) 15 combinations(3, 1), (3, 2), (3, 3), (3, 4), (3, 5)In reality the column values might be very correlated and only thefollowing combinations exist:(1, 1), (2, 2), (2, 3), (3, 4), (3, 5) 5 combinationsIn case of „=“ conditions on these columns the CBO would nowexpect that 1/15 of all table records fulfill these conditions while inreality in average 1/5 of all table records fit.

© SAP 2007 /


What can be done to reduce the risk to run into trouble:Avoid redundant, correlated conditions in database queries.Specify an appropriate index or join hint in order to force the optimalaccess path.In rare situations it can even make sense to specify a CARDINALITYhint in order to make the CBO aware about the right cardinality:

/*+ CARDINALITY(<table_name_or_alias> <cardinality>) */

Upgrade to Oracle >= 10.2.0.4 where some useful new features areincluded and activated. See the example on the next slides for moredetails.

The cardinality estimated by the CBO is usually too low ifthere are conditions on correlated columns.

© SAP 2007 /


Example:

We create a table ORDERDATES with 360.000 order numbers(ORDERNUM column) and three date related columns YEAR, MONTH andQUARTER.The dates are equally distributed between January 2000 (represented as‚200001‘ and December 2009 (‚200912‘):

10 YEAR values: 2000, 2001, ..., 2009120 MONTH values: 2000.001, 2000.002, ..., 2009.01240 QUARTER values: 200001, 200002, ..., 200904

Furthermore statistics and two indexes are created on this table – oneindex on ORDERNUM and one index on the date columns.The number of distinct values are (as expected):

COLUMN_NAME NUM_DISTINCT

------------------------------ ------------

ORDERNUM 360000

YEAR 10

MONTH 120

QUARTER 40

© SAP 2007 /


The date columns are 100 % correlated. So the following two selectionswould return exactly the same number of records (3000):

MONTH = '2008.012'MONTH = '2008.012' AND YEAR = '2008' AND QUARTER = '200804‘

Theoretically the CBO could know about this correlation because theDISTINCT_KEYS of index ORDERDATES_1 are 120.Now let‘s see how the CBO behaves in different environments.

© SAP 2007 /


Example (Oracle 9.2.0):

ALTER SESSION SET OPTIMIZER_FEATURES_ENABLE = '9.2.0';ALTER SESSION SET OPTIMIZER_DYNAMIC_SAMPLING = 1;ALTER SESSION SET "_FIX_CONTROL" = "5765456:0";

EXPLAIN PLAN FORSELECT * FROM ORDERDATES WHEREYEAR = '2008' AND MONTH = '2008.012' AND QUARTER = '200804';

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

----------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost |----------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 8 | 216 | 1 || 1 | TABLE ACCESS BY INDEX ROWID| ORDERDATES | 8 | 216 | 1 ||* 2 | INDEX RANGE SCAN | ORDERDATES_1 | 8 | | 1 |----------------------------------------------------------------------------

Instead of the real cardinality of 3000 the CBO calculates a cardinality ofonly 8.This would be the average cardinality of uncorrelated columns:

<estimated rows> = NUM_ROWS / NDV(YEAR) / NDV(MONTH) / NDV(QUARTER) =

360000 / 10 / 120 / 40 =

7.5

© SAP 2007 /


Example (Oracle 10.2.0.2):

ALTER SESSION SET OPTIMIZER_FEATURES_ENABLE = '10.2.0.2';ALTER SESSION SET OPTIMIZER_DYNAMIC_SAMPLING = 2;ALTER SESSION SET "_FIX_CONTROL" = "5765456:0";



--------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |--------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 8 | 216 | 7 (15)| 00:00:01 || 1 | TABLE ACCESS BY INDEX ROWID| ORDERDATES | 8 | 216 | 6 (0)| 00:00:01 ||* 2 | INDEX RANGE SCAN | ORDERDATES_1 | 3000 | | 3 (0)| 00:00:01 |--------------------------------------------------------------------------------------------

The estimated rows in the INDEX RANGE SCAN line are calculatedproperly (because the DISTINCT_KEYS are taken into account with10.2.0.2), but the more important final value is still at only 8.In this inconsistent state the single table access can benefit from betterindex cardinality estimations, but for joins the problem remainsunchanged (because always the final estimated rows are evaluated).

© SAP 2007 /


Example (Oracle 10.2.0.4 with simplified column group statistics):




--------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |--------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 3000 | 81000 | 7 (15)| 00:00:01 || 1 | TABLE ACCESS BY INDEX ROWID| ORDERDATES | 3000 | 81000 | 6 (0)| 00:00:01 ||* 2 | INDEX RANGE SCAN | ORDERDATES_1 | 3000 | | 3 (0)| 00:00:01 |--------------------------------------------------------------------------------------------

The estimated rows are calculated correctly with 3000.The reason is that the DISTINCT_KEYS of the index are now evaluated forboth index and table selectivity.The column group statistics on 10.2.0.4 only rely on the DISTINCT_KEYSvalue and are therefore only possible if an index on the columns exist.On Oracle 11g index-independent column group statistics can begenerated with DBMS_STATS.

© SAP 2007 /


Example (Oracle 10.2.0.4 with increased dynamic sampling):




--------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |--------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 4332 | 114K| 9 (0)| 00:00:01 || 1 | TABLE ACCESS BY INDEX ROWID| ORDERDATES | 4332 | 114K| 9 (0)| 00:00:01 ||* 2 | INDEX RANGE SCAN | ORDERDATES_1 | 4332 | | 4 (0)| 00:00:01 |--------------------------------------------------------------------------------------------

Using dynamic sampling the CBO is able to recognize that a significantamount of records fulfill the selection criteria.This works only if literals are available during parsing. With bind variablesdynamic sampling is not done!

© SAP 2007 /


What have we learnt from that example so far?

There is a continuous improvement in the cardinality estimation withcorrelated columns:

Oracle 9i: Correlations are not considered at all.Oracle 10.2.0.2: Correlations are only considered for the index accessby taking into account the distinct keys of the index.Oracle 10.2.0.4: Correlations are considered using dynamic samplingand simplified column group statistics.Oracle 11g: General column group statistics are available(independent of existing indexes).

© SAP 2007 /


Let‘s continue the example and look at a simple join:

For that purpose we create an additional table ORDERS that also contains360.000 orders (ORDERNUM column) with 18.000 different types(ORDERTYPE column).The ORDERTYPEs are equally distributed, so 20 records exist for eachORDERTYPE value.Additionally we create an index ORDERS_0 on ORDERNUM and an indexORDERS_1 on ORDERTYPE.

© SAP 2007 /


ALTER SESSION SET OPTIMIZER_FEATURES_ENABLE = '9.2.0';ALTER SESSION SET OPTIMIZER_DYNAMIC_SAMPLING = 1;ALTER SESSION SET "_FIX_CONTROL" = "5765456:0";SET AUTOTRACE TRACEONLY

SELECT * FROM ORDERDATES D, ORDERS O WHERED.ORDERNUM = O.ORDERNUM ANDD.YEAR = '2008' AND D.MONTH = '2008.012' AND D.QUARTER = '200804' ANDO.ORDERTYPE = '16190';

-----------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost |-----------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 7 | 273 | 3 || 1 | NESTED LOOPS | | 7 | 273 | 2 || 2 | TABLE ACCESS BY INDEX ROWID| ORDERDATES | 8 | 216 | 1 ||* 3 | INDEX RANGE SCAN | ORDERDATES_1 | 8 | | 1 ||* 4 | TABLE ACCESS BY INDEX ROWID| ORDERS | 1 | 12 | 0 ||* 5 | INDEX UNIQUE SCAN | ORDERS_0 | 1 | | |-----------------------------------------------------------------------------

Statistics----------------------------------------------------------

9035 consistent gets1 rows processed

Join example (Oracle 9.2.0):

Due to the optimistic cardinality estimation the CBO enters the join viaORDERDATES (3000 records). In reality ORDERS would be the better entrypoint (20 records.

© SAP 2007 /


ALTER SESSION SET OPTIMIZER_FEATURES_ENABLE = ‘10.2.0.2';ALTER SESSION SET OPTIMIZER_DYNAMIC_SAMPLING = 2;ALTER SESSION SET "_FIX_CONTROL" = "5765456:0";SET AUTOTRACE TRACEONLY


---------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |---------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 7 | 273 | 8 (0)| 00:00:01 || 1 | NESTED LOOPS | | 7 | 273 | 8 (0)| 00:00:01 || 2 | TABLE ACCESS BY INDEX ROWID| ORDERDATES | 8 | 216 | 6 (0)| 00:00:01 ||* 3 | INDEX RANGE SCAN | ORDERDATES_1 | 3000 | | 3 (0)| 00:00:01 ||* 4 | TABLE ACCESS BY INDEX ROWID| ORDERS | 1 | 12 | 0 (0)| 00:00:01 ||* 5 | INDEX UNIQUE SCAN | ORDERS_0 | 1 | | 0 (0)| 00:00:01 |---------------------------------------------------------------------------------------------

Statistics----------------------------------------------------------


Join example (Oracle 10.2.0.2):

Same problem like with Oracle 9.2.0, because the 3000 rows are onlyexpected in the index, but not from the table ORDERDATES.

© SAP 2007 /




---------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |---------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 20 | 780 | 9 (0)| 00:00:01 || 1 | NESTED LOOPS | | 20 | 780 | 9 (0)| 00:00:01 || 2 | TABLE ACCESS BY INDEX ROWID| ORDERS | 20 | 240 | 5 (0)| 00:00:01 ||* 3 | INDEX RANGE SCAN | ORDERS_1 | 20 | | 1 (0)| 00:00:01 ||* 4 | TABLE ACCESS BY INDEX ROWID| ORDERDATES | 1 | 27 | 0 (0)| 00:00:01 ||* 5 | INDEX UNIQUE SCAN | ORDERDATES_0 | 1 | | 0 (0)| 00:00:01 |---------------------------------------------------------------------------------------------

Statistics----------------------------------------------------------


Join example (Oracle 10.2.0.4 with simplified column group statistics):

Good access because now the CBO recognizes the high number ofrecords to be returned from ORDERDATES

© SAP 2007 /




---------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |---------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 20 | 780 | 9 (0)| 00:00:01 || 1 | NESTED LOOPS | | 20 | 780 | 9 (0)| 00:00:01 || 2 | TABLE ACCESS BY INDEX ROWID| ORDERS | 20 | 240 | 5 (0)| 00:00:01 ||* 3 | INDEX RANGE SCAN | ORDERS_1 | 20 | | 1 (0)| 00:00:01 ||* 4 | TABLE ACCESS BY INDEX ROWID| ORDERDATES | 1 | 27 | 0 (0)| 00:00:01 ||* 5 | INDEX UNIQUE SCAN | ORDERDATES_0 | 1 | | 0 (0)| 00:00:01 |---------------------------------------------------------------------------------------------

Statistics----------------------------------------------------------


Join example (Oracle 10.2.0.4 with increased dynamic sampling):

Good access because now the CBO recognizes the high number ofrecords to be returned from ORDERDATES; 340 logical reads, becausewith dynamic sampling (level 7) 256 blocks are sampled.

© SAP 2007 /


Summary:

The correlation issue was one of the most serious problems in the area ofCBO and complex queries in the past.Starting with 10.2.0.4 the increased dynamic sampling level and thesimplified column group statistics already provide good improvement.The increased dynamic sampling level takes only effect in combinationwith literals. With bind variables there is no benefit.With Oracle 11g it will be possible to create individual column groupstatistics dependent on the needs (and independent from existingindexes). This is another major step to cope with the correlation issue.

© SAP 2007 /

The STAR Transformation Problem

What is the STAR transformation problem?

Dimensions used in a STAR transformation are typically accessed asecond time outside of the STAR transformation with a normal join.The estimated selectivity is therefore applied twice. If the CBO assumes aselectivity of 1 % for a dimension, it will finally result in a selectivity of 1% * 1 % = 0.01 %.So for almost all STAR transformation accesses the „estimated rows“will finally be significantly too low.A side effect is that large result sets from the STAR transformation areerroneously used as driving set in a hash or nested loop join sequence.This results in a high runtime overhead because big hash tables have tobe built (in case of hash joins) or many accesses to the inner tables arenecessary (nested loop join).Oracle bug 5648287 describes this problem.

© SAP 2007 /


Real Life Example

In this example you can see an extremely optimistic CBO expectation (e.g.estimated rows: 1; real rows: 680388) that is – among others – caused bythe STAR transformation problem.As a workaround the effects of the STAR transformation problem wereegalized by increasing the statistics value for the number of records ofthe fact table by the same factor.Afterwards the runtime was about 6 times faster.

https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/d0ec9621-28af-2b10-ada5-99a587282d74

© SAP 2007 /


What can be done?

Apply a fix for Oracle bug 5648287. This fix is included in CBO mergefix15 for 10.2.0.2 (note 981875) and CBO mergefix 6 for 10.2.0.4 (note1165319).As a workaround it often helps to increase the NUM_ROWS statisticsvalue of the fact table using DBMS_STATS.SET_TABLE_STATS (see note724545).Sometimes a close look at the dimensions of the STAR transformation isuseful. If there is one dimension where the CBO expects a irrealistic lowselectivity (that is then taken into account twice), changes to thisdimension (e.g. new CBO statistics) can help.

© SAP 2007 /

Some Other Typical Problems

The 0 records problem:

The CBO sometimes comes to the conclusion that it is very unlikely (butnot impossible) that in a certain step of the join chain any record isreturned. In this case it may assume a cardinality that is very close to 0(e.g. 0.03).In the execution plan this cannot be seen directly, because the displayedvalue is always the next higher integer value ( 1).An indirect indication for a 0 record problem is:

Join of two tables without any join condition (e.g. two differentdimension tables in BI) AND„Estimated rows“ for at least one of the tables > 1 AND„Estimated rows“ for the whole join = 1

Small inaccuracies in the CBO statistics or CBO bugs can result in the 0records problem.

© SAP 2007 /


Possible solutions for the 0 records problem:

Identify and resolve possible problems with CBO statistics.Make sure that a recent CBO mergefix is applied.Set the following Oracle parameter in order to make sure that the CBOalways calculates with at least 1 row rather than fraction of 1:

_OPTIMIZER_NEW_JOIN_CARD_COMPUTATION = FALSE

© SAP 2007 /


The join range problem:

If join conditions use ranges (e.g. X.COL1 <= Y.COL2) the CBO works witha default selectivity of 5 %.In reality this assumption is often too optimistic and perhaps 50 % aremore realistic.This becomes particularly critical if a high number of join rangeconditions are used (e.g. many date comparisons between differenttables).In the worst case an inadequate join will be used and the performance cango down dramatically.

Possible solutions:

Avoid using several join range conditions in one query.Use standard approaches like Oracle hints or adaptations of CBOstatistics.

© SAP 2007 /


The bind variable problem:

Whenever bind variables are used (and no peeking is active), the CBOuses fix filter factors for the estimated rows:

„=“, „IN“: 1 / NUM_DISTINCT„<“, „>“, „<=“, „>=“, „LIKE“: 1 / 20 ( 5 %)BETWEEN: 1 / 400 ( 0.25 %)

If you select popular values or large ranges the estimated rows can bemuch smaller than the reality.Example:

SELECT … WHERE BUDAT BETWEEN :A0 and :A1:A0 = ‚19000101‘; :A1 = ‚99993112‘In reality all records (100 %) are returned a very large range between1900 and 9999 is selected.The CBO uses the BETWEEN row filter factor of 0.25 %.There is already a factor of 400 between reality and estimationThis can be responsible for bad join orders and decreasedperformance.

© SAP 2007 /


Possible solutions for the bind variable problem:

Avoid using unselective ranges and values in the WHERE clause (iffeasible).Consider using the DBI hints &SUBSTITUTE VALUES& or &SUBSTITUTELITERALS& in order to substitute bind variables with the real valuesduring parsing (note 129385)Use standard approaches like Oracle hints or adaptations of CBOstatistics.

© SAP 2007 /

Appendix

Why did OPTIMIZER_DYNAMIC_SAMPLING = 6 not work in the example?

With a dynamic sampling level of 6 Oracle reads 128 blocks duringparsing in order to determine the correlation of the specified columns.In the case that no record in these blocks fulfills the WHERE clause,dynamic sampling is deactivated and the normal cost and row calculationapproach is used.This is definitely a better idea than assuming that really no record fulfillsthe WHERE clause.In our example the records in the table were sorted in a very specificorder and so only a few Oracle blocks contained records that fulfilled theWHERE clause. All 128 sampled blocks were different from the blockswith the fitting records.See the following document with some more analysis details:Dynamic Sampling Analysis

https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/707b2612-29af-2b10-69b4-a554d591da95

© SAP 2007 /

Copyright 2008 SAP AGAll rights reserved

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changedwithout prior notice.Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, Duet, Business ByDesign, ByDesign, PartnerEdge and other SAP products and services mentioned herein as well as theirrespective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned andassociated logos displayed are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This documentcontains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy,and/or development. SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, orother items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties ofmerchantability, fitness for a particular purpose, or non-infringement.

SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitationshall not apply in cases of intent or gross negligence.The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in thesematerials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages

Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durchSAP AG nicht gestattet. In dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert werden.Einige von der SAP AG und deren Vertriebspartnern vertriebene Softwareprodukte können Softwarekomponenten umfassen, die Eigentum anderer Softwarehersteller sind.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, Duet, Business ByDesign, ByDesign, PartnerEdge und andere in diesem Dokument erwähnte SAP-Produkte und Servicessowie die dazugehörigen Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und in mehreren anderen Ländern weltweit. Alle anderen in diesem Dokument erwähntenNamen von Produkten und Services sowie die damit verbundenen Firmenlogos sind Marken der jeweiligen Unternehmen. Die Angaben im Text sind unverbindlich und dienen lediglich zuInformationszwecken. Produkte können länderspezifische Unterschiede aufweisen.

Die in diesem Dokument enthaltenen Informationen sind Eigentum von SAP. Dieses Dokument ist eine Vorabversion und unterliegt nicht Ihrer Lizenzvereinbarung oder einer anderenVereinbarung mit SAP. Dieses Dokument enthält nur vorgesehene Strategien, Entwicklungen und Funktionen des SAP®-Produkts und ist für SAP nicht bindend, einen bestimmtenGeschäftsweg, eine Produktstrategie bzw. -entwicklung einzuschlagen. SAP übernimmt keine Verantwortung für Fehler oder Auslassungen in diesen Materialien. SAP garantiert nicht dieRichtigkeit oder Vollständigkeit der Informationen, Texte, Grafiken, Links oder anderer in diesen Materialien enthaltenen Elemente. Diese Publikation wird ohne jegliche Gewähr, wederausdrücklich noch stillschweigend, bereitgestellt. Dies gilt u. a., aber nicht ausschließlich, hinsichtlich der Gewährleistung der Marktgängigkeit und der Eignung für einen bestimmten Zwecksowie für die Gewährleistung der Nichtverletzung geltenden Rechts.

SAP übernimmt keine Haftung für Schäden jeglicher Art, einschließlich und ohne Einschränkung für direkte, spezielle, indirekte oder Folgeschäden im Zusammenhang mit der Verwendungdieser Unterlagen. Diese Einschränkung gilt nicht bei Vorsatz oder grober Fahrlässigkeit.Die gesetzliche Haftung bei Personenschäden oder die Produkthaftung bleibt unberührt. Die Informationen, auf die Sie möglicherweise über die in diesem Material enthaltenen Hotlinkszugreifen, unterliegen nicht dem Einfluss von SAP, und SAP unterstützt nicht die Nutzung von Internetseiten Dritter durch Sie und gibt keinerlei Gewährleistungen oder Zusagen überInternetseiten Dritter ab.

Alle Rechte vorbehalten.

oracle cost based optimizer (cbo) and its optimism about cardinalities%3a typical problem situations

Documents