readme_rdbms.htm

Debian中文参考手册,系统介绍了Debian系统

<p CLASS="BP">Another general problem when converting data to a different
character set is data loss because the output database character set is
not a superset of the input character set. To avoid data loss problems,
be sure to follow the guidelines in the <i>Oracle9</i>i <i>Globalization
Support Guide</i>.
<br><a NAME="559026"></a><!--TOC=h2-"559026"-->
<h3 CLASS="H2">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">7.2 External
Table Restrictions</font></font></h3>
<!--/TOC=h2--><a NAME="559035"></a><!--TOC=h3-"559035"-->
<h4 CLASS="H3">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">7.2.1 External
Table Directory Objects</font></font></h4>
<!--/TOC=h3--><a NAME="559928"></a>

<p CLASS="BP">A user must have privileges explicitly granted rather than
through roles in order to access an external table directory object. Otherwise,
the user may or may not have access to the directory object.
<br><a NAME="559929"></a><!--TOC=h3-"559929"-->
<h4 CLASS="H3">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">7.2.2 Whitespace
in TERMINATED BY String</font></font></h4>
<!--/TOC=h3--><a NAME="559933"></a>

<p CLASS="BP">If the access parameters for an external table specify <tt>TERMINATED
BY</tt> with a string that only contains whitespace (blanks, tabs, and
so on), then also specifying <tt>ENCLOSED BY</tt> for the same field will
cause all rows to be rejected. An example of this is shown below.
<pre CLASS="CE"><a NAME="559939"></a>ACCESS PARAMETERS (FIELDS&nbsp;&nbsp;
<a NAME="559973"></a>(DEPTNO CHAR(10)&nbsp; TERMINATED BY "&nbsp; " ENCLOSED BY "(" AND ")"),&nbsp;&nbsp;
<a NAME="559974"></a>DNAME CHAR(30))
<a NAME="559975"></a></pre>
<a NAME="559943"></a>

<p CLASS="BP">The problem is the code that parses the fields will skip
all whitespace after the last enclosing delimiter is found before it looks
for a terminator string. After the whitespace is skipped, the code then
looks for the terminator, but since all whitespace has been skipped, the
delimiter is not found. There is no single workaround to this problem,
though omitting the <tt>TERMINATED BY</tt> clause may work in some cases.
<br><a NAME="559999"></a><!--TOC=h2-"559999"-->
<h3 CLASS="H2">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">7.3 Oracle
Locale Builder Utility</font></font></h3>
<!--/TOC=h2--><a NAME="560003"></a>

<p CLASS="BP">When using the Locale Builder utility to create new locale
definitions, it is important for the users to review the semantics of their
changes according to SQL specifications. If the generated locale object
contains custom formats, for example, a custom date/time format, which
does not conform to SQL standards, the users may experience runtime errors
when trying to activate their new locale definitions. Therefore, it is
advisable that the users take extra care in creating custom formats and
validating their changes.
<br><a NAME="560042"></a>

<p CLASS="BP">When adding classification data for customized multibyte
character sets, users should base the definition on an 8-bit or multibyte
character set, since classification verification for multibyte character
sets does not apply to 7-bit character sets.
<br><a NAME="559930"></a><!--TOC=h2-"559930"-->
<h3 CLASS="H2">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">7.4 Miscellaneous
Utilities Issues</font></font></h3>
<!--/TOC=h2--><a NAME="522045"></a><!--TOC=h3-"522045"-->
<h4 CLASS="H3">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">7.4.1 Restriction
for the DBMS_METADATA Package and the Oracle Shared Server Environment</font></font></h4>
<!--/TOC=h3--><a NAME="522047"></a>

<p CLASS="BP">The new <tt>DBMS_METADATA</tt> package (See<i> Oracle9</i>i
<i>Supplied PL/SQL Packages and Types Reference</i>) generates database
object definitions as either XML or SQL DDL. In an OSS environment, it
must disable session migration and connection pooling. This results in
any shared server process servicing a session that runs the package to
effectively become a default, dedicated server for the life of the session.
Make sure sufficient shared servers are configured when the package is
used and that the number of servers is not artificially limited by too
small a value for the <tt>MAX_SHARED_SERVERS</tt> initialization parameter.
<br><a NAME="522057"></a><!--TOC=h3-"522057"-->
<h4 CLASS="H3">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">7.4.2 New
Waits Parameter Supported in TKPROF Utility</font></font></h4>
<!--/TOC=h3--><a NAME="522058"></a>

<p CLASS="BP">A new parameter called <tt>Waits</tt> is now supported in
the <tt>TKPROF</tt> Utility. With this fix a new parameter, <tt>wait information</tt>
is available for <tt>tkprof</tt>. The parameter has a default value of
<tt>yes</tt>. When set to <tt>yes</tt>, any wait events captured in the
trace file will result in a summary that is produced per cursor involved,
along with a overall summary for recursive and non-recursive calls for
each wait event encountered. The summary will include count, max and sum
aggregates for each wait event. To disable the feature, specify <tt>waits=no</tt>.
<br><a NAME="561275"></a><!--TOC=h3-"561275"-->
<h4 CLASS="H3">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">7.4.3 Change
in DBNEWID Behavior</font></font></h4>
<!--/TOC=h3--><a NAME="561278"></a>

<p CLASS="BP">The changing of the database name does not require a resetlogs,
therefore all previous backups are still useable. However, all datafiles
require the header to be updated so all datafiles must first be placed
into read-write mode. In addition, the following text is displayed if the
database name has been changed successfully.
<pre CLASS="CE"><a NAME="561284"></a>Database name changed to PROD12.
<a NAME="561285"></a>Modify parameter file and generate a new password file before restarting.&nbsp;
<a NAME="561288"></a>Succesfully changed database name.
<a NAME="561289"></a>DBNEWID - Completed succesfully.</pre>
<a NAME="521440"></a><!--TOC=h1-"521440"-->
<h2 CLASS="H1">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">8 SQL EXECUTION</font></font></h2>
<!--/TOC=h1--><a NAME="521416"></a><!--TOC=h2-"521416"-->
<h3 CLASS="H2">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">8.1 Plan
Stability and OR Expansion</font></font></h3>
<!--/TOC=h2--><a NAME="479074"></a>

<p CLASS="BP">For execution plans that involve <tt>OR</tt> expansion, you
should avoid using stored outlines if possible. This recommendation is
due to the nature of stored outlines, which use hints to influence the
execution plan, and to the nature of <tt>OR</tt> expansion, which is represented
internally through a set of <tt>OR</tt> chains, each of which represents
a distinct join order. Hints are only useful for influencing a single join
order, because there is no way to target a specific <tt>OR</tt> chain.
Therefore an outline's hints are applied to the first <tt>OR</tt> chain
represented internally. The net effect is that these hints simply get propagated
across the remaining <tt>OR</tt> chains by the optimizer, often leading
to suboptimal execution plans that differ from the originally saved plans.
<br><a NAME="479078"></a>

<p CLASS="BP">Workaround:
<br><a NAME="479080"></a>

<p CLASS="BP">Stored outlines that involve <tt>OR</tt> expansion can be
identified by querying the <tt>USER_OUTLINE_HINTS</tt> view for hint text
containing <tt>USE_CONCAT</tt>. Issue the following query:
<pre CLASS="CE"><a NAME="479084"></a>&nbsp;&nbsp;&nbsp; SELECT NAME, HINT FROM USER_OUTLINE_HINTS WHERE HINT LIKE 'USE_CONCAT%';</pre>
<a NAME="479088"></a>

<p CLASS="BP">Any outline containing this hint should either be dropped
using the <tt>DROP OUTLINE</tt> command or moved to an unused category
with the following command:
<pre CLASS="CE"><a NAME="479092"></a>&nbsp;&nbsp;&nbsp; ALTER OUTLINE &lt;outline-name> CHANGE CATEGORY TO &lt;unused-category-name>;</pre>
<a NAME="524534"></a><!--TOC=h2-"524534"-->
<h3 CLASS="H2">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">8.2 EXPLAIN
PLAN and V$SQL_PLAN</font></font></h3>
<!--/TOC=h2--><a NAME="524535"></a>

<p CLASS="BP">In Oracle9<i>i</i>, there are circumstances where <tt>EXPLAIN
PLAN</tt> cannot be used to predict the execution plan for a query with
certainty. The optimizer can peek at the value of a user bind variable
at the first invocation of the query and use that value in generating an
execution plan. That plan may be different from the plan that would be
produced by <tt>EXPLAIN PLAN</tt>. The peeking feature is enabled if the
parameter <tt>optimizer_features_enable</tt> is set to Oracle9<i>i</i>
release 9.0.0 or higher. There can also be differences between <tt>EXPLAIN
PLAN</tt> and the plan the optimizer would generate for actually running
the query if the parameter <tt>cursor_sharing</tt> is set to similar. To
obtain the actual execution plan for a cursor, use <tt>v$sql_plan</tt>.
<br><a NAME="525611"></a><!--TOC=h2-"525611"-->
<h3 CLASS="H2">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">8.3 Multi
Join Key Pre-Fetching</font></font></h3>
<!--/TOC=h2--><a NAME="525614"></a>

<p CLASS="BP">This feature enables parallel reads during a table lookup
nested loop join. When activated, the table lookup node is pushed up above
the nested loop join node in the <tt>EXPLAIN PLAN</tt> output. This allows
blocks containing rows matching multiple join key values to be prefetched
in parallel with a single vector read.
<br><a NAME="525620"></a>

<p CLASS="BP">This change to the <tt>EXPLAIN PLAN</tt> output is not considered
a different execution plan. It does not affect the join order, join method,
access method, or parallelization scheme.
<br><a NAME="556323"></a><!--TOC=h2-"556323"-->
<h3 CLASS="H2">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">8.4 GROUP
BY Clause</font></font></h3>
<!--/TOC=h2--><a NAME="556324"></a>

<p CLASS="BP">The <tt>GROUP</tt> <tt>BY</tt> clause does not define a sort
order. If you have not specified an <tt>ORDER</tt> <tt>BY</tt> clause in
your <tt>SELECT</tt> statement, and have been relying on the row order
returned by the DBMS, you may see a different result order in Oracle9<i>i</i>
release 2. Refer to the <tt>GROUP</tt> <tt>BY</tt> clause in the <i>Oracle9</i>i
<i>SQL Reference</i> for more information.
<br><a NAME="556075"></a><!--TOC=h1-"556075"-->
<h2 CLASS="H1">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">9 TRANSPARENT
APPLICATION FAILOVER</font></font></h2>
<!--/TOC=h1--><a NAME="479260"></a>

<p CLASS="BP">Select Failover is implemented by transparently re-executing
the <tt>SELECT</tt> statement and then bringing the cursor up to the same
point as it was before the failure. Thus, if the original query took an
hour, failing over the query will also take about an hour. Also, Select
Failover only occurs after Session Failover has occurred. Thus, if a client
is doing a parallel query and a slave fails, the query will not be transparently
restarted.
<br><a NAME="521877"></a><!--TOC=h1-"521877"-->
<h2 CLASS="H1">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">10 MEDIA
MANAGEMENT SOFTWARE</font></font></h2>
<!--/TOC=h1--><a NAME="556342"></a>

<p CLASS="BP">In this release, Oracle has bundled a new version of the
Legato backup and recovery software for Oracle databases. This is a single
version of Legato NetWorker and the NetWorker Module for Oracle client,
which has been designed to operate on the same server as your Oracle database.
After installing this version of Legato NetWorker, you will receive a license
notice each time you back up your database to tape using the Oracle Recovery
Manager (RMAN) interface. To eliminate this license notice, you can enter
an authorization code, which can be obtained directly from Legato without
charge. Instructions for obtaining this code are in the displayed license
notice.
<br><a NAME="557908"></a>

<p CLASS="BP">Oracle no longer distributes Legato documentation. Legato
NetWorker documentation can be obtained directly from Legato and can be
found at the following Web site:
<br><a NAME="557947"></a>

<p CLASS="BP"><tt><a href="http://www.legato.com/lssv/">http://www.legato.com/lssv/</a></tt>
<br><a NAME="557948"></a>

<p CLASS="BP">This site will also contain any product updates for this
NetWorker version.
<br><a NAME="557912"></a>

<p CLASS="BP">If you have previously installed and used Legato Storage
Manager (LSM) on your Oracle database server, you can uninstall it and
install this new version of Legato NetWorker. Any backups made by LSM are
still usable by the new Legato NetWorker software.
<br><a NAME="479540"></a><!--TOC=h1-"479540"-->
<h2 CLASS="H1">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">11 LOBs</font></font></h2>
<!--/TOC=h1--><a NAME="517384"></a><!--TOC=h2-"517384"-->
<h3 CLASS="H2">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">11.1 SQL
Functions on LOBs</font></font></h3>
<!--/TOC=h2--><a NAME="517385"></a>

<p CLASS="BP">For single byte and multibyte character set data, including
varying-width character sets, the following functions have known issues:
<br><a NAME="528218"></a>

<p CLASS="BP"><tt>NVL</tt>
<br><a NAME="528219"></a>

<p CLASS="BP"><tt>COUNT</tt>
<br><a NAME="528220"></a>

<p CLASS="BP"><tt>DECODE</tt>
<br><a NAME="517388"></a>

<p CLASS="BP"><tt>NVL</tt> and <tt>COUNT</tt>: bug1475475 ORA-00932 when
using <tt>NVL()</tt> or <tt>COUNT()</tt> on <tt>CLOB</tt>.
<br><a NAME="517389"></a>

<p CLASS="BP"><tt>DECODE</tt>: bug 1473512 - ORA-0932 in <tt>DECODE</tt>
(<tt>NCHAR</tt>,<tt>NCLOB</tt>,<tt>NCHAR</tt>,<tt>NCHAR</tt>) in PL/SQL
<br><a NAME="560206"></a><!--TOC=h2-"560206"-->
<h3 CLASS="H2">
<font face="Arial, Helvetica, sans-serif"><font color="#330099">11.2 Passing
Temp LOB Parameters Between Different Languages</font></font></h3>
<!--/TOC=h2--><a NAME="560208"></a>

<p CLASS="BP">This note applies to you if you:
<ul CLASS="LB1">
<li CLASS="LB1" TYPE="DISC">
<a NAME="560222"></a>are using <b>temporary</b> LOBs. This note does not
apply if you are using only persistent LOBs.</li>

<li CLASS="LB1" TYPE="DISC">
<a NAME="560224"></a>have JAVA or C functions/procedures published to SQL
and PL/SQL using a call specification. This note does not apply to functions
or procedures implemented in PL/SQL.</li>

<li CLASS="LB1" TYPE="DISC">
<a NAME="560227"></a>have a parameter of a LOB type or an object type with
an embedded LOB attribute which is declared as an <tt>IN</tt> parameter.</li>

<li CLASS="LB1" TYPE="DISC">
<a NAME="560229"></a>have the LOB parameter or attribute being written
into inside the function/procedure.</li>

<li CLASS="LB1" TYPE="DISC">
<a NAME="560231"></a>have a temporary LOB being passed in for that parameter
during invocation.</li>

<br>&nbsp;
<p>&nbsp;</ul>
<a NAME="560234"></a>

<p CLASS="BP">When a temporary LOB (either standalone or embedded inside
an object) is passed as an <tt>IN</tt> parameter to a procedure (or function)
implemented in Java or C, and the LOB is written into the procedure, the
caller of the procedure will not see the modifications made inside the
procedure. If the caller needs to see the modifications, the LOB parameter
must be declared as an <tt>IN OUT</tt> parameter.
<br><a NAME="560241"></a>

<p CLASS="BP">Prior to Oracle9<i>i </i>release 2, even if the LOB parameter
was declared as <tt>IN</tt> instead of <tt>IN OUT</tt>, changes made to
temporary LOBs in