Re: Oracle EE 12.1 standardize on bigfile tablespaces?

  • From: Seth Miller <sethmiller.sm@xxxxxxxxx>
  • To: cstephens16@xxxxxxxxx
  • Date: Mon, 20 Feb 2017 10:57:18 -0600

Chris,

The only other downsize I have run into is transportable tablespaces. In
that case, if the data files are really big I usually use an OS utility
like split to break apart the files for transport.

One other weird thing I ran into is that rconfig doesn't take into account
whether a data file is bigfile or smallfile so whatever you have your
database default set to is what rconfig uses when creating data files. It
wasn't a problem until rconfig tried to create a smallfile undo tablespace
for a new instance that was larger than 32GB. The point is, if you are
planning on going with bigfile, make sure to change your default tablespace
type to bigfile.

However, in my opinion the advantages for bigfile far outweigh these few
exceptions.


Seth Miller

On Mon, Feb 20, 2017 at 8:46 AM, Chris Stephens <cstephens16@xxxxxxxxx>
wrote:

Weekly level 0, daily level 1, hourly archivelogs.  We plan to include
section size in our backup scripts.

On Mon, Feb 20, 2017 at 8:19 AM Niall Litchfield <
niall.litchfield@xxxxxxxxx> wrote:

What is your backup approach? The unit of backup is generally the data
file. AFAIK RMAN parallel backup still doesn't automatically calculate
section size in the absence of declaring it. If your bigfiles aren't really
big, that's not a problem - but for terabyte-sized datafile backups to slow
media it will be.

On Mon, Feb 20, 2017 at 1:59 PM, Chris Stephens <cstephens16@xxxxxxxxx>
wrote:

We are in the process of building a new Exadata system that will host a
relatively large number of 12.1 EE RAC databases.  We are trying to keep
everything as simple as possible and are currently planning on
standardizing on bigfile tablespaces for all application data.

Are there any downsides/reasons to not do this?

Thanks,
chris




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


Other related posts: