Re: ORA-02294 only on some parallel PK validates
- From: "John Hurley" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "hurleyjohnb@xxxxxxxxx" for DMARC)
- To: "rjoralist3@xxxxxxxxxxxxxxxxxxxxx" <rjoralist3@xxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 22 May 2014 11:38:49 -0400
Sometimes no avoiding fighting it out with support *** sigh ***
Sent from my iPhone
> On May 22, 2014, at 11:22 AM, "Rich Jesse" <rjoralist3@xxxxxxxxxxxxxxxxxxxxx>
> wrote:
>
> Mark replies:
>
>> It is unclear to me why you do not proceed with the 15 indentified tables
>> non-parallel, if that works repeatably.
>
> This is the first time I've seen this. My concern is that this is both
> unpredictable and apparently undocumented. I'll be running this process
> again tomorrow, so I'll be able to see which, if any, PKs are affected.
>
>> With so many objects available to run in separate threads, it is unclear to
>> me that parallel is an advantage for any of this process.
>
> The largest table takes 4 hours to create its PK single-threaded. All 4600+
> PKs take 45m total with DOP of 8. No matter how I divide the list, it will
> take a minimum of 4h if I don't use parallel.
>
>> In fact, if you decide to go that way, I would expect a significant
>> reduction in the overall elapsed time. For tables that will fit in the
>> buffer cache, you might want to run a scanner to get nice clean blocks in
>> there just before you unleash the index creates for that table, with a
>> thread for each index create on a cached table.
>
> I'm dying to test this on our future production DB server as the buffer
> cache could nearly fit every table at the time of this part of the
> migration. I <3 new hardware. :) I'll also have 2x more cores to throw at
> it, but I'm wondering if that could make this problem worse with increased
> contention.
>
> Thanks!
>
> Rich
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
