Re: share a new 11gR2 feature

>
> 1.2.2.4 IGNORE_ROW_ON_DUPKEY_INDEX Hint for INSERT Statement
>
> With INSERT INTO TARGET...SELECT...FROM SOURCE, a unique key for some
> to-be-inserted rows may collide with existing rows. The
> IGNORE_ROW_ON_DUPKEY_INDEX allows the collisions to be silently ignored and
> the non-colliding rows to be inserted. A PL/SQL program could achieve the
> same effect by first selecting the source rows and by then inserting them
> one-by-one into the target in a block that has a null handler for the
> DUP_VAL_ON_INDEX exception. However, the PL/SQL approach would take effort
> to program and is much slower than the single SQL statement that this hint
> allows.
>

This same functionality has been available since 10g (I believe) using
DBMS_ERRLOG<http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28419/d_errlog.htm#BABGGCDF>.
In short, an error table is created and all the rows that error out are
inserted there.  Which of course allows you to do set operations instead of
row-by-row.  You'll still have to figure what to do with those errors (if
anything).


On Thu, Sep 3, 2009 at 10:16 AM, Job Miller <jobmiller@xxxxxxxxx> wrote:

> A few of the things from the 11gR2 new features guide that are interesting
> to me. i just cut and paste from the doc, so no value add but if anyone
> feels inspired to share the things from the 11gR2 new features guide that
> they have been waiting for or think they can immediately benefit from, I am
> sure the rest of us would gain a better appreciation for that new feature.
>  So if you plan to read the guide, ignore this.
>
> http://download.oracle.com/docs/cd/E11882_01/server.112/e10881/chapter1.htm
>
>
> 1.2.2.4 IGNORE_ROW_ON_DUPKEY_INDEX Hint for INSERT Statement
>
> With INSERT INTO TARGET...SELECT...FROM SOURCE, a unique key for some
> to-be-inserted rows may collide with existing rows. The
> IGNORE_ROW_ON_DUPKEY_INDEX allows the collisions to be silently ignored and
> the non-colliding rows to be inserted. A PL/SQL program could achieve the
> same effect by first selecting the source rows and by then inserting them
> one-by-one into the target in a block that has a null handler for the
> DUP_VAL_ON_INDEX exception. However, the PL/SQL approach would take effort
> to program and is much slower than the single SQL statement that this hint
> allows.
>
> 1.9.1.5 ASM Intelligent Data Placement
>
> Disk drives have higher transfer rates and bytes per track on the outer
> tracks. This makes it preferable to keep the hotter data closer to the edge
> of the disk; that is, the lower numbered blocks. This feature enables ASM to
> identify higher performance disk regions. Most frequently accessed ASM files
> can be marked to be moved into the hot region and take advantage of higher
> I/O performance (for example, hot tablespaces and indices) and able to
> better meet the application I/O demand. This feature is only applicable when
> whole physical disks are presented to ASM versus local unit numbers (LUN).
>
> 1.9.2.11 Exadata Simulation
>
> For a given workload, you can now simulate the possible benefits in I/O
> interconnect throughput that can be obtained from migration to Exadata
> architecture. SQL Performance Analyzer, a feature of Oracle Real Application
> Testing, allows simulation to be performed on a non-Exadata installation
> without needing to provision the Exadata system. The SQL Performance
> Analyzer Exadata simulation feature can be used to identify workloads that
> are good candidates for Exadata migration.
>
> This feature simplifies simulation and testing of workloads for Exadata
> migration system change without requiring provisioning of Exadata hardware.
>
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>


-- 
chet justice
www.oraclenerd.com

Other related posts: