转载自：http://www.itpub.net/351520,2.html
摘自：expert one-on-one oracle (P554)
設置cussor_sharing=force之後，會有以下的情況：
• Optimizer related issues – CURSOR_SHARING will remove all character string
and numeric constants from the query; the optimizer will have less information to
work with. This may very well result in different query plans.
• Query output related issues – The lengths of columns that your query fetches will
unexpectedly change. Queries that used to return a VARCHAR2(5) and a
NUMBER(2), might start returning a VARCHAR2(30) and a NUMBER(5). The
actual size of the data returned wonʹt change, but the application will be told the
potential for a 30 byte column is there – reports and other related applications may
be affected.
• Query plans are harder to evaluate – This is due to the fact that EXPLAIN PLAN
will ʹseeʹ a different query than the database does. This makes query tuning more
difficult. Features like AUTOTRACE in SQL*PLUS are unreliable with
CURSOR_SHARING.
摘自：expert one-on-one oracle (P554)
設置cussor_sharing=force之後，會有以下的情況：
• Optimizer related issues – CURSOR_SHARING will remove all character string
and numeric constants from the query; the optimizer will have less information to
work with. This may very well result in different query plans.
• Query output related issues – The lengths of columns that your query fetches will
unexpectedly change. Queries that used to return a VARCHAR2(5) and a
NUMBER(2), might start returning a VARCHAR2(30) and a NUMBER(5). The
actual size of the data returned wonʹt change, but the application will be told the
potential for a 30 byte column is there – reports and other related applications may
be affected.
• Query plans are harder to evaluate – This is due to the fact that EXPLAIN PLAN
will ʹseeʹ a different query than the database does. This makes query tuning more
difficult. Features like AUTOTRACE in SQL*PLUS are unreliable with
CURSOR_SHARING.
