- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Oracle Storage - Cooked To RAW - What are the ...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-04-2004 08:15 AM
тАО11-04-2004 08:15 AM
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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-04-2004 08:24 AM
тАО11-04-2004 08:24 AM
SolutionWe 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-04-2004 08:25 AM
тАО11-04-2004 08:25 AM
Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-04-2004 08:39 AM
тАО11-04-2004 08:39 AM
Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-04-2004 08:56 AM
тАО11-04-2004 08:56 AM
Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-04-2004 09:04 AM
тАО11-04-2004 09:04 AM
Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-04-2004 09:26 AM
тАО11-04-2004 09:26 AM
Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?
read the doc:
"Best practices for Oracle on HP-UX"
http://h21007.www2.hp.com/dspp/files/unprotected/database/HP3KOracle.ppt
Regards,
Zygmunt
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-04-2004 09:56 AM
тАО11-04-2004 09:56 AM
Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?
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
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-04-2004 05:17 PM
тАО11-04-2004 05:17 PM
Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-05-2004 12:43 AM
тАО11-05-2004 12:43 AM
Re: Oracle Storage - Cooked To RAW - What are the implications to our Backup Strategy?
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.