Re: share a new 11gR2 feature
Date: Thu, 3 Sep 2009 10:36:30 -0700 (PDT)
Message-ID: <113819.55093.qm_at_web38902.mail.mud.yahoo.com>
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_at_gmail.com> To: chet.justice_at_gmail.com
Cc: jobmiller_at_yahoo.com; oracle-l_at_freelists.org 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_at_gmail.com> 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_at_yahoo.com> 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
>
>
-- Niall Litchfield Oracle DBA http://www.orawin.info -- http://www.freelists.org/webpage/oracle-lReceived on Thu Sep 03 2009 - 12:36:30 CDT