Operating System - HP-UX
1748028 Members
5213 Online
108757 Solutions
New Discussion юеВ

Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?

 
SOLVED
Go to solution
Alzhy
Honored Contributor

Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?

Due to some DBA's pointing to reference configurations of record breaking UNIX TPMC peformance - which are all RAW, there are plans to move our multi-TB instances to RAW. From a storage management/conversion perspective I have no problem converting their current datafiles to raw. My only question centers on how our backups will change.

Our current backup strategy is to use BusinessCopy on our EVAs (plans are ahead to use VxVM so we can do inter-EVA or EVA-XP mirrors..) and we use NetBackup to push the data to tape. I am sure NetBackup can do RAW volume backups and my questions are:

1) Will the HotBackup-DB suspend-split approach still work unmodified if Oracle is now dealing with raw storage as opposed to filesystems?

2.) Is RAW storage safe from a server panic/unscheduled reboot standpoint? With Filesystem/cooked storage -- we have a log to replay with so damage is minimal but in the case of raw storage - Will oracle be intelligent enough to recover?

I've had RAW storage experience before but with Informix and Sybase and both handles crashes gracefully...

Any inputs will be greatly appreciated.

Hakuna Matata.
13 REPLIES 13
Sanjay_6
Honored Contributor
Solution

Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?

Hi Nelson,

We were backing up a multi-TB raw database using netbackup and from the backup /restore standpoint we did not had any problem. As far as the database recovery is concerned in the case of a panic / reboot, oracle has its own strategies for recovering from a system / db crash.

Since the db is so big, your dba's are probably using the db in archive mode and it rolls back any transaction that was completely recorded / updated in the database at the time of database recovery following a system / db crash.

Hope this helps.

Regds
Sanjay_6
Honored Contributor

Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?

A mistake in my earlier post,

read

it rolls back any transaction that was completely recorded / updated

as

it rolls back any transaction that was not completely recorded / updated

Sorry abt that.

Thanks
Sanjay
Alzhy
Honored Contributor

Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?

Sanjay,

Thanks for the info.. Yes all our DB's are in archive log mode (BTW, are both your archive log and redo log storage on RAW as well?). Do you actually do split-mirror type of backups ?

Also, do you use pointers to your RAW volumes/disks? I am planning to simply create pointers to the actual raw device files so there is minimal changes that the DBAs will do. We'll be using a mix of RAW Disks/LUNs (/dev/rdsk/cXtYdZ) and LVM raw lvols that will be striped.

Hakuna Matata.
Sanjay_6
Honored Contributor

Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?

Hi Nelson,

We have multiple situation. In some situations, we have everything for the db on raw lvs. In another situation we have a mix of raw / filesystem lv structure for the database.

The backup scenario we use primarily is symmetrix SRDF. the EMC connects, sync up and the database shutdown happens, the emc split happens and the database is started on the backup node to check that the sync was okay and then it is shutdown and the backup kicked off from the backup node. successful db startup confirmation sent to primary node and the db is started on primary node and made is available for the users while the backup is going on from the backup server.

Our DB storage is primarily raw lvs striped across 8 luns on the EMC. To keeps things organized, we create standard 2GB lvs and let the dba use as many as they want. We add more lvs to the db as and when the demand arises to add more tablespace.

Hope this helps.

Regds
Sanjay
A. Clay Stephenson
Acclaimed Contributor

Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?

I always use "pointers" (better known as symbolic links) to translate between oracle files and raw devices. This also serves as at least a minimal form of documentation. One of the biggest dangers to raw i/o is you. It's very easy to assume that a given LVOL is unused (and Sam will help you to decide that it's unused) when in fact it's vital to Oracle.

Unless you are running Oracle RAC, I think that you will find that the gains are not very great and, in fact, my findings under 11.11 with plenty of memory is that cooked files actually do better than raw i/o. This was not the case under 10.20 or 11.0. Buffer cache should probably be in the range of 800-1600 MB and I prefer static by setting a non-zero bufpages value. My best performance under 11.11 typically occurs with cooked files, about 1500GB of buffer caches, and whomping big (~3GB) SGA's.




If you have OnlineJFS, let me suggest a much less painful method of testing. Mount your tables and indices using convosync=direct,mincache=direct,nodatainlog. This will bypass the UNIX buffer cache and is persformance is essentially indistinguishable from that of raw i/o; moreover; all your conventional back tools still work.

If it ain't broke, I can fix that.
Zygmunt Krawczyk
Honored Contributor

Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?

Hi Nelson,
read the doc:
"Best practices for Oracle on HP-UX"
http://h21007.www2.hp.com/dspp/files/unprotected/database/HP3KOracle.ppt

Regards,
Zygmunt
Steven E. Protter
Exalted Contributor

Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?

A Clay answered a thread of mine on this topic by essentially letting us all know that there were not much of a gain to be had on 11i.

You lose a lot as a systems administrator. A cold backup on a cooked filesystem is a database shutdown and file copy. Its a little more complex, probably forcing you to use the rman utility to backup the database.

1-Correctly configured the hot standby database will be just as reliable either way.

2-No real difference, just harder to backup and restore the database, harder to manage space, because bdf gets you nothing.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Hein van den Heuvel
Honored Contributor

Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?

The TPC test execute relatively light transactions, never parsing any, generating relatively high IO rates. The IO processing is significant for them, and any speedup there will be useful. IF (big if) disk IO takes 10% of the CPU time and RAW saves 10% of that, then the resulting 1% system savinf are worth it for TPC results. But for regular work? Direct-io will get you most of the available benefit.

This generally does NOT apply to your typical business work. There, much more CPU time is spend parsing, creating processes and so on. Just look at the usertime vs system time. RAW will only reduce system time, not usertime. Is the target system doing 10,000 IO/sec or 1,000 IO/sec. For the former it may be worth it, for the latter... no.

No while I find the potential benefit of RAW overhyped, I also find the 'management nightmare' of RAW exagerated.

With the softlinks as pointed out before, some clear LVM LV naming, and a little adminitration driven by Oracle's DBA_DATA_FILES tables there is not much too it... except for the lack of auto-extent.

Back to specific questions.

- EVA BC work on the PV level below the VG.
They work as well for LVs carved from those used by filesystems or raw. No difference.

- REDOs (and TEMP and UNDOs) are your prime and first RAW usage areas. (IMHO). Why? Heavy IO, and no need to backup! For example, you can just temporarely flip to (small) redo files just before a (file based) backup starts, and recreate raw Redo after the backup. An easy script!
- ARCHIVES are NOT candidates for RAW.

Finally... it is not an all or nothing situation. Oracle is parfectly happy having some raw devices (high IO), and some files (automatic extents).

Good luck!

Hein.





Alzhy
Honored Contributor

Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?

Another round of replies and I will close this thread.

Why do most of the UNIX DB benchmarks from SUN to HP have storage on RAW then? Is this becuase it's the standard for these benchmarks (ie. TPC?) If I recall, some years ago in a shopp that was migrating from mainframe to UNIX and evaluating platforms - we actually bought the TPC suite and in it it really does not force you to use RAW. Has anyone tried TPC yet on Filesystems?

Our Databases have on average anyware from 20 to 30 Gigabytes of SGA. On our biggest server (a 64GB system) .. I/O's average a sustained 7,000 to 10,000 I/O's per sec. and about 120-150 MB per sec. Currently we've the filesystems on "DirectIO" and VxFS 3.5 and performance is still deemed unacceptable. Planning to go QuickIO but cost is deemed prohibitive - software maintenance alone will be significant.

Some of you claim DirectIO'd cooked filesystems approaches or even exceeds raw implementations with minimal buffer cache allocations -- will this be a general rule these days for 11i + Oracle 9/10 environments?

I did ask the author of HP's Clustering technologies once who claimed he actually still consider himslef a "performance" sepcialist.. with a wink .. he said, "RAW is still faster no matter what." He even mentioned a figure ~ at least 20 per cent and significant memory savings.

Hakuna Matata.