Re: share a new 11gR2 feature
- From: Robert Freeman <robertgfreeman@xxxxxxxxx>
- To: niall.litchfield@xxxxxxxxx, chet.justice@xxxxxxxxx
- Date: Thu, 3 Sep 2009 10:36:30 -0700 (PDT)
Active database duplication is available in Release 1.
No target database duplication requires a recovery catalog.
RF
Robert G. Freeman
Oracle ACE
Author:
Oracle Database 11g RMAN Backup and Recovery (Oracle Press) - ON IT'S WAY SOON!
OCP: Oracle Database 11g Administrator Certified Professional Study Guide
(Sybex)
Oracle Database 11g New Features (Oracle Press)
Portable DBA: Oracle (Oracle Press)
Oracle Database 10g New Features (Oracle Press)
Oracle9i RMAN Backup and Recovery (Oracle Press)
Oracle9i New Features (Oracle Press)
Other various titles out of print now...
Blog: http://robertgfreeman.blogspot.com
The LDS Church is looking for DBA's. You do have to be a Church member in
good standing. A lot of kind people write me, concerned I may be breaking
the law by saying you have to be a Church member. It's legal I promise! :-)
http://pages.sssnet.com/messndal/church/parachurch.pdf
________________________________
From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
To: chet.justice@xxxxxxxxx
Cc: jobmiller@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Sent: Thursday, September 3, 2009 9:22:47 AM
Subject: Re: share a new 11gR2 feature
I really like the look of
DUPLICATE DATABASE TO dupdb
UNTIL TIME "TO_DATE('11/01/2007 14:00:00', 'MM/DD/YYYY HH24:MI:SS')"
SPFILE
BACKUP LOCATION '/prod_backups'
NOFILENAMECHECK;
i.e duplicate without connection to production db.
and
DUPLICATE TARGET DATABASE TO dupdb
FROM ACTIVE DATABASE
PASSWORD FILE
SPFILE
NOFILENAMECHECK;
i.e duplicate from the live db without a backup.
Niall
On Thu, Sep 3, 2009 at 3:30 PM, chet justice <chet.justice@xxxxxxxxx> wrote:
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. 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.
>>
>>
>>
>>
>>--
>>//www.freelists.org/webpage/oracle-l
>>
>>
>>
>
>
>--
>chet justice
>www.oraclenerd.com
>
>
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
Other related posts:
