praveen_katta
asked on
Raw Partitions vs. File Systems for Sybase ASE 12.5 on HP-UX
We have Sybase ASE 12.5 Database server running on a HP-UX B.11.11 U 9000/800 with
SAN (SYMMETRIX 8830) using rawpartitions. We are in the middle of moving the SAN to a new Disk Array DMX8.
Our SAs have brought up the option of using File Systems instead of raw partitions. I would like
to see if any of you have anyexperiences in moving from raw to file systems. We do have asynch io enabled with raw partitions now. In the past versions, i experienced performance
problems using file systems and I was not able to bring up the devices using asynch io.
Does Sybase has any recommendations (URLs) on this? Are there any issues taking this path of filesystems?
SAN (SYMMETRIX 8830) using rawpartitions. We are in the middle of moving the SAN to a new Disk Array DMX8.
Our SAs have brought up the option of using File Systems instead of raw partitions. I would like
to see if any of you have anyexperiences in moving from raw to file systems. We do have asynch io enabled with raw partitions now. In the past versions, i experienced performance
problems using file systems and I was not able to bring up the devices using asynch io.
Does Sybase has any recommendations (URLs) on this? Are there any issues taking this path of filesystems?
Last Comment
ASKER CERTIFIED SOLUTION
THIS SOLUTION IS ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
Sure, but we're talking about ASE 12.5 where that isn't available. 8-)
I've seen that whitepaper before... it isn't clear whether this gets past OS limitations on processes issuing synchronous reads to files. I'll have to double-check that when I'm on a platform that has that behaviour.
I've seen that whitepaper before... it isn't clear whether this gets past OS limitations on processes issuing synchronous reads to files. I'll have to double-check that when I'm on a platform that has that behaviour.
ASKER
Joe,
Thanks a lot for all your comments. I support going to raw partitions. As a matter of fact, I received the following response from Sybase Tech support also, which is inline.
Hi Praveen,
My name is Robert Weeks. I am the Technical Support Engineer assigned to your case involving use of filesystem devices.
The issue with filesystem devices, on Unix platforms, is the question of filesystem buffering. This feature of the Unix OS allows the OS to write data to files faster. It involves placing filesystem updates in a buffer rather than immediately writing them to disk. There is an inherent risk in this practise, however, in that, if the system were to crash, any updates in the buffer at the time of the crash would be lost rather than applied to disk. In database applications this can lead to severe corruption problems requiring recovery from backups.
Consequently, Sybase recommends against use of filesystem devices in situations in which data integrity and recoverability are important. For a database like tempdb, this is not needed so filesystem devices would be ideal in such cases. Similarly, a read-only database, or a database that is frequently recovered from an external data source might be good candidates for such filesystem devices as well.
There are ways around the issue as well. You can use the T-SQL DSYNC option to the DISK INIT command when creating ASE devices on Unix filesystem partitions. This option instructs the OS to complete the write to disk immediately rather than use buffering.
Also, on some Unix platforms, the OS offers filesystem features that may protect against this kind of buffering, although Sybase cannot vouch for such and, therefore, does not officially support use of them.
Use of the DSYNC option does avoid the filesystem buffering issue, but there is a performance hit from using this. How much of a
hit would be variable, depending on such factors as throughput. You should do testing in your system to see if use of this would be feasible in your particular situation.
You can find further discussion of these issues in the ASE Reference Manual entry for the DISK INIT command. The URL for this would be:
http://manuals.sybase.com/onlinebooks/group-as/asg1251e/commands/@Generic__BookTextView/22476;hf=0#X
and in the ASE Troubleshooting Guide:
http://manuals.sybase.com/onlinebooks/group-as/asg1251e/svrtsg/@Generic__BookView
Please review this and let me know if you have any further questions about this matter, or if the case should now be closed, when you get the chance.
Thanks,
Robert Weeks
Sybase Technical Support
800-879-2273
rweeks@sybase.com
Thanks a lot for all your comments. I support going to raw partitions. As a matter of fact, I received the following response from Sybase Tech support also, which is inline.
Hi Praveen,
My name is Robert Weeks. I am the Technical Support Engineer assigned to your case involving use of filesystem devices.
The issue with filesystem devices, on Unix platforms, is the question of filesystem buffering. This feature of the Unix OS allows the OS to write data to files faster. It involves placing filesystem updates in a buffer rather than immediately writing them to disk. There is an inherent risk in this practise, however, in that, if the system were to crash, any updates in the buffer at the time of the crash would be lost rather than applied to disk. In database applications this can lead to severe corruption problems requiring recovery from backups.
Consequently, Sybase recommends against use of filesystem devices in situations in which data integrity and recoverability are important. For a database like tempdb, this is not needed so filesystem devices would be ideal in such cases. Similarly, a read-only database, or a database that is frequently recovered from an external data source might be good candidates for such filesystem devices as well.
There are ways around the issue as well. You can use the T-SQL DSYNC option to the DISK INIT command when creating ASE devices on Unix filesystem partitions. This option instructs the OS to complete the write to disk immediately rather than use buffering.
Also, on some Unix platforms, the OS offers filesystem features that may protect against this kind of buffering, although Sybase cannot vouch for such and, therefore, does not officially support use of them.
Use of the DSYNC option does avoid the filesystem buffering issue, but there is a performance hit from using this. How much of a
hit would be variable, depending on such factors as throughput. You should do testing in your system to see if use of this would be feasible in your particular situation.
You can find further discussion of these issues in the ASE Reference Manual entry for the DISK INIT command. The URL for this would be:
http://manuals.sybase.com/onlinebooks/group-as/asg1251e/commands/@Generic__BookTextView/22476;hf=0#X
and in the ASE Troubleshooting Guide:
http://manuals.sybase.com/onlinebooks/group-as/asg1251e/svrtsg/@Generic__BookView
Please review this and let me know if you have any further questions about this matter, or if the case should now be closed, when you get the chance.
Thanks,
Robert Weeks
Sybase Technical Support
800-879-2273
rweeks@sybase.com
I totally agree you have to use DSYNC with files to make them safe... and that DSYNC imposes a large performance hit, as it undoes the only performance benefit of filesystem devices (write buffering). So your choices are : files that are safe, with writes performing the same as raw partitions and reads performing more slowly, or files that are not safe.
Robert's best advice was to test it both ways and see. This should be a multi-user test to properly assess the effects of synchronous reads! I'm pretty confident you'll see a performance penalty for files. It might be a penalty you can live with - maybe it's worth losing 15-25% to ease the maintenance.
Robert's best advice was to test it both ways and see. This should be a multi-user test to properly assess the effects of synchronous reads! I'm pretty confident you'll see a performance penalty for files. It might be a penalty you can live with - maybe it's worth losing 15-25% to ease the maintenance.
Storage
Computer data storage, often called storage or memory, is a technology consisting of computer components and recording media used to retain digital data. In addition to local storage devices like CD and DVD readers, hard drives and flash drives, solid state drives can hold enormous amounts of data in a very small device. Cloud services and other new forms of remote storage also add to the capacity of devices and their ability to access more data without building additional data storage into a device.
45K
Questions
--
Followers
--
Top Experts
Get a personalized solution from industry experts
TRUSTED BY
ASKER
http://www.sybase.com/detail?id=1043413