Re: Big files

I pretty much agree with Andy - bigfile and ASM are a great fit. I'd also
argue that bigfile tablespaces only really start to make compelling sense
for a very few shops typically where:
   - Individual *tablespace* sizes are pretty large (a 300GB 8k blocksize
   tablespace will only require 10 datafiles after all, 3TB requires 100 ) and
   - there isn't a sensible way to add more tablespaces and keep ease and
   consistency of management

or

   - you meet the consistent transaction response times I describe in the
   blog post Eric refers to.

Of course you might chose to use bigfile without needing to and I can't see
any downside other than the recovery issue Andy describes below.

Niall


On Wed, Jan 11, 2012 at 4:10 AM, Andy Colvin <acolvin@xxxxxxxxxxx> wrote:

> One thing of note is that on versions below 11.1, rman will not be able to
> break a bigfile tablespace into multiple chunks when taking backups using
> parallelism.  Starting with 11.1, rman can break a large file into multiple
> pieces using the section size parameter.
> From my experience, I would only create bigfile tablespaces on ASM.  It's
> generally easier to expand ASM diskgroups than individual filesystems.
>
> Andy Colvin
>
> Principal Consultant
> Enkitec
> andy.colvin@xxxxxxxxxxx
> http://blog.oracle-ninja.com
>
> On Jan 9, 2012, at 8:09 PM, G wrote:
>
> > Does anyone have opinions/experience/preferences on bigfile tablespaces?
> I had someone ask recently, but I have always used smallfile tablespaces.
> >
> > Sent from my iPhone--
> > http://www.freelists.org/webpage/oracle-l
> >
> >
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>


-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info


--
http://www.freelists.org/webpage/oracle-l

Other related posts: