Re: share a new 11gR2 feature

From: Howard Latham <howard.latham_at_gmail.com>
Date: Fri, 4 Sep 2009 11:06:41 +0100
Message-ID: <713d96d10909040306o53e47306pe4305d370225ad8c_at_mail.gmail.com>

I can confirm that the second one works Luverley!

BUT the auxiliary must not be auto registered otherwise you get a blocking connections message.
Minor I know but its the subject of a bug! And it makes 10g database duplication look tiresome!

2009/9/3 Niall Litchfield <niall.litchfield_at_gmail.com>

> 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<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_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
>

-- 
Howard A. Latham

--
http://www.freelists.org/webpage/oracle-l

Received on Fri Sep 04 2009 - 05:06:41 CDT