Re: Insert into partitioned tables and specifying the partition name

  • From: amonte <ax.mount@xxxxxxxxx>
  • To: Greg Rahn <greg@xxxxxxxxxxxxxxxxxx>
  • Date: Sun, 11 Apr 2010 21:12:49 +0200

Hello

Do you know why when dbwr and lgwr is writing (db file parallel write and
log file parallel write) the whole system just freezes...?

When we are loaidng data sometimes the load time increases from 4 minute to
20 and it happens when we observe this sort of "freeze", dbwr and lgwr busy
writing. This can takes ñike 5 to 50 minutes


TIA



2010/4/10 Greg Rahn <greg@xxxxxxxxxxxxxxxxxx>

> Autoextend is the other operation that can cause issues in this case.
> I know there are bugs logged against this scenario, but as you
> mentioned, the increment for the autoextend should be large enough
> such that the allocation is infrequent (doing anything too frequently
> when it can be avoided is a bad thing).
>
> Personally I'm not a big fan of autoextend - I understand where/why it
> can be desirable but I'd rather size out stuff by calculation and
> monitor it and adjust as necessary.  That's not to say there is
> anything wrong with it.
>
> I think that bigfile is a fine idea, its just that there are certain
> "corner/edge" cases where it can cause a little headache, and if using
> RAC it can exacerbate this a bit.  The two specifically that come to
> mind are
> 1) autoextend increment being too small
> 2) segment next extent being too small
> Both of these put the file header block (block 2) in demand and when
> there is only one file and one header block it can cause (undesired)
> waits, however, making the next allocations large enough should
> alleviate these issues.
>
> The other issue that I am vaguely aware of is that RMAN is unable to
> use parallelism for bigfile backups until 11.2 (IIRC).
>
> On Sat, Apr 10, 2010 at 4:47 AM, amonte <ax.mount@xxxxxxxxx> wrote:
> > After checking the datafile autoextend looks like it can cause the
> problems
> > I am seeing since the autoextend is set to 100M only. Just changed it to
> > 512M. Will see how it affects the performance
> >
> > Finally is bigfile really a good idea in 10g?
>
> --
> Regards,
> Greg Rahn
> http://structureddata.org
>

Other related posts: