Re: 2gb filesize, large disks and splitting tablespaces

andrew_webby at hotmail wrote:
>
> A post I just saw of Niall's reminded me of something. I'm on
> Solaris7/Oracle 816 (Sparc) and remember the dire warnings in days of yore
> about unix 'largefiles', ie. files over 2gb in size.
>
> ps. Volume Manager 3.0.4, VXFS 3.3.2
>
> I know Solaris7 has support for them, and I (think I) know Oracle is fine
> with it, but in this combination? Yay? Nay? Eh? Horror stories? Success?
>
> In fact, what is the current thinking these days regarding large disks?
> Reason I ask is at the moment, the array is populated with 4gb disks (!),
> but the new array coming is 18gb disks.
>
> As an *example*: suppose I have an 18gb disk and at the moment, I have 3x2gb
> files making a 6gb tablespace. Assuming *just for the sake of argument* I
> had to put these on the one disk, would you still place them in 3 files on
> that disk or in one file?
>
> Any advantages one way or the other d'ya think? Such a thing as 'datafile
> header contention'? Are the db_writer's more 'intelligent' with multiple
> files?
>
> Discuss....
>
> Andrew :o)

Excluding the 2g issues in terms of OS bugs, Oracle bugs etc, the reason I'm a fan of 2G or less is

1. its a lot easier to move 2G around than (say) 8G. I can run several moves in parallel to make maintenance quicker, similarly I can back up them in parallel (although most streaming backup solutions can now do that with larger files anyway)
2. More files means less inode contention for the files (in particular temporary tablespaces). There is a known bug at the moment with vxfs and 8.1.x (fixed in 8.1.7.1 maybe) where you get a slowdown because of nasty vxfs level locking (workaround is to use raw or quick IO)

hth
connor

-- 
==============================
Connor McDonald

http://www.oracledba.co.uk

"Some days you're the pigeon, some days you're the statue..."