Re: BigFile Tablespaces

  • From: Tanel Põder <tanel.poder.003@xxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 15 Jul 2004 22:22:00 +0300

> Trying to wade through the new 10G features. About bigfile tablespaces and
> ASM. If I understand it right, isn't this Oracle's way of trying to
> implement something along the lines of the S.A.M.E methodology?

We'll I think ASM's idea is much cooler than SAME, due additional
flexibility and features (like redistributing IO etc.).
But since ASM is very fresh and proprietary right now, I suggest to keep
your redologs (and archivelogs) out from ASM on a decent filesystem or raw
devices - that way you'll be able to fully recover from backup even when ASM
instance hits the fan.

But if you wonder why bigfile tablespaces may contain only one datafile,
then the reason is backwards compatibility and rowids.
Rowids in bigfile tablespace have 32 bits reserved for data block number in
given datafile file. In a smallfile tablespace rowid you have only 22 bits
for specifying block number and the rest 10 bits were for stating in which
datafile (relative to segment's tablespace) the data block resides. So,
Oracle just "moved" 10 additional bits in rowid from one use to another,
keeping the rowid sizes the same.

This means that, allowing some internal overhead, in a smallfile tablespace
you can have 1022 datafiles, each consisting of up to 2**22-1 = 4 million
blocks.
In a bigfile tablespaces, you can have only 1 datafile, consisting up to
2**32-1 = 4 billion blocks.

The total sizes add up the same, but for a multi-petabyte database it might
not be reasonable to hold tens of thousands of files in database, for
various reasons like opening or checkpointing the database. Also there is a
database wide limit - you can't have more than 65533 files in an Oracle
database (Once when I tested it, I did hit some other limit near 30000
files).

Tanel.


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: