Re: Big files
- From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
- To: acolvin@xxxxxxxxxxx
- Date: Thu, 12 Jan 2012 12:03:43 +0000
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--
> > //www.freelists.org/webpage/oracle-l
> >
> >
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
--
//www.freelists.org/webpage/oracle-l
Other related posts:
