Comments for orawin.info

Comment on Metric Collection Error by Mel

Mel — Thu, 26 Jan 2012 10:49:56 +0000

Good stuff, exactly where I was looking for!!

Thanks
Mel

Comment on Adding Datafiles by joel garry

joel garry — Wed, 11 Jan 2012 23:38:15 +0000

I have a (ridiculous old) habit of fixing data files at 2G, except for the last at 200M with 64M autoextend, 2G max. When the last start to extend, I up it to 2G and add another autoextend. I see if I make space one way or another in the existing data files, new data gets added in those first, before any more autoextending. If I have lots of fixed empty data files (as in dropping user, create new, imp data), Oracle round-robins. Adding or major extending datafiles is noticeable both in system response and large fields of blue in dbconsole. hp-ux itanium raid-5 10.2.0.4 YMMV.

I should check out that rman backing up in chunks thing some time, thanks for that.

Comment on Adding Datafiles by Niall Litchfield

Niall Litchfield — Fri, 06 Jan 2012 10:16:43 +0000

Martin

The short answer is that I haven’t checked. I’m assuming that any sensible oracle shop is using some lower level striping of I/O as you describe. All I think I am really arguing is that there is still erhaps a case for adding datafiles rather than autoextend even here IFF (if and only if) you have such a critical system that you don’t want to hold up real processing at all.

BTW I mentally substituted extents for segments in your comment, I assume that is what you intended.

Comment on Proof by extension.. by Log Buffer #253, A Carnival of the Vanities for DBAs | The Pythian Blog

Log Buffer #253, A Carnival of the Vanities for DBAs | The Pythian Blog — Fri, 06 Jan 2012 06:02:21 +0000

[...] is the performance overhead of datafile autoextend events? Niall Litchfield [...]

Comment on Adding Datafiles by Martin Berger

Martin Berger — Thu, 05 Jan 2012 21:00:33 +0000

Niall,
have you ever checked how the extends are distributed over the datafiles if you just add datafiles?
Let’s say you always add a datafile when the tablespace hits 90%, and there is only data added. So your first datafile is 90% filled when the 2nd datafile is added. I assume now all new segments are filled in file2 until this is also 90% full. Then the segments are distributed over all 2 files until they both reach 95% and you add another datafile. This again fills until it reaches 95%, afterwards all 3 datafiles gets segments until 97%, alarm, datafile, etc.
Do you see the pattern? if you graph the files left to right and fill them bottom up you get inverted “L”s.
In this case the io-performance will be quite different depending which part of the “L” you are accessing.
Of course sometimes the striping is done on lower systems (ASM, VolumeManager, StorageSubsystem), but in that case the number of files is independent at all.

Comment on Adding Datafiles by Abhishek

Abhishek — Thu, 05 Jan 2012 19:35:22 +0000

This is a piece of art.
-Abhishek

Comment on OUI Updates feature by Log Buffer #250, A Carnival of the Vanities for DBAs | The Pythian Blog

Log Buffer #250, A Carnival of the Vanities for DBAs | The Pythian Blog — Fri, 16 Dec 2011 06:01:53 +0000

[...] to download any post release recommended updates for the product and to apply them at install time. Nial gives [...]

Comment on About by Sandipan

Sandipan — Thu, 15 Dec 2011 03:35:18 +0000

Hi,

I need to appear for Oracle Enterprise Manager 11g Essentials Exam (1Z0-530). Can you suggest me how should I prepare myself for the same.

Thanks,
Sandipan

Comment on UKOUG Agenda by Four (good) days in December « Oracle Observations

Four (good) days in December « Oracle Observations — Thu, 17 Nov 2011 23:39:12 +0000

[...] http://orawin.info/blog/2011/11/15/ukoug-agenda-2/ [...]

Comment on New Features, New Defaults, New Side-Effects by Uwe Hesse

Uwe Hesse — Thu, 17 Nov 2011 16:43:26 +0000

Thank you, Niall, for pointing out these pitfalls associated with Deferred Segment Creation! The sequence problem is fixed in 11.2.0.3 meanwhile, but the Standard Edition downgrade problem still exists, I think.