Re: 20 TB Bigfile
Date: Tue, 10 Mar 2015 15:47:04 -0400
Message-ID: <54FF4A38.3030307_at_yahoo.com>
Hi Keith,
Stefan has mentioned multi-section backups, which will speed up you backup, but not above what's possible on the channel. Better question would be why would you want to go with big file tablespaces? What would be the advantage? By increasing block size to 16K, you can have 1023 64GB disks in a single ASM disk group. Do you really need to go above that?
On 03/10/2015 03:26 PM, Keith Moore wrote:
> Hi,
>
> Sorry, I meant to include the version. It is version 11.2.0.3.6.
>
> The strategy is to never restore from backups except as a last resort. We will
> failover to the DR database if possible. If not, then restore from a storage
> level snapshot of production and archive logs.
>
> If the failure scenario is such that neither of those is feasible, we would
> restore from the RMAN backup. In that case, a full restore will be slow
> whether it's a single big file or many smaller files. The only case where it
> would make a difference is if we had a small file tablespace and only needed
> to restore a single data file.
>
> Keith
>
>
>> Hi Keith, unfortunately you have not mentioned the
>> database version. However as this database is related to SAP,
>> bigfile tablespaces are supported with  11.2.0.2 (or newer)
>> and BR*Tools 7.20 Patch Level 20 (or newer). Please check
>> SAPnote #1644762 for more details.  The max size limit with
>> 1023 data files would be 32 TB with the Oracle/SAP 8 kb
>> requirement - so you still have plenty of space to go in your
>> scenario.    You have to export/import
>> with R3load (and/or Distribution Monitor) in the SAP standard
>> scenario as you migrate from Solaris (assuming SPARC and Big Endian)
>> to Linux (Little Endian). In this scenario it is very easy to split
>> the objects into several tablespaces due to modifications in R3load
>> files.   However the backup & restore
>> scenario is critical, if you still want to go with bigfile
>> tablespaces. You can use RMAN (or have to in case of ASM)
>> with multi section backups to parallelize the backups.
>>   Best Regards
>> Stefan Koehler
>>
>> Freelance Oracle performance consultant and researcher
>> Homepage: http://www.soocs.de
>> Twitter: _at_OracleSK
>> > Keith Moore <kmoore_at_zephyrus.com> hat am 10. März 2015 um
>> 13:23 geschrieben:
>> >
>> > We have a client who is moving a SAP database from Solaris (non-ASM) to
>> Linux
>> > (ASM). This database is around 21 TB but 20 TB of that is a single
>> tablespace
>> > with 1023 data files (yes, the maximum limit).
>> >
>> > On the new architecture we are considering using a single 20 TB Bigfile
>> > tablespace. Does anyone know of any negatives to doing that? Bugs?
>> > Performance? Other?
>> >
>> > Moving the data into multiple tablespaces will not be an option.
>> >
>> > Thanks
>> > Keith Moore -- http://www.freelists.org/webpage/oracle-l
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
-- Mladen Gogala Oracle DBA http://mgogala.freehostia.com -- http://www.freelists.org/webpage/oracle-lReceived on Tue Mar 10 2015 - 20:47:04 CET