Working in IT can be both rewarding and aggravating. Rewarding because there is nothing more exciting than creating solutions and products that make a genuine difference to peoples lives. Equally, in IT Support, not much matches that thrill of solving problems quickly and efficiently. I frankly have always loved that feeling of success: It was broken… I fixed it.
But IT work can also be aggravating, because whatever part of the solution or product is your ‘baby’, you can end up feeling that regardless of what the problem is, your ‘baby’ is always held to blame. Talk to anyone in the network support team, and they know this challenge: “The system is slow! It must be the network!”
DBAs also know this all too well: “The website is slow! It must be the database!”
Unsurprisingly, what this leads to is a search for features and functions that can bullet proof your system. “What can I do to eliminate the potential that my area of concern is indeed the cause of all my IT departments woes?”
Oracle DBAs have a number of configuration choices that can make a huge difference. Lets look at two:
ASM
ASM is an alternative to building your database on top of a file system. So rather than an AIX admin saying, “Here is a JFS2 file system running on a volume group that I am managing”, Its more like the storage admin saying “Here are a bunch of disk subsystem volumes. Knock yourself out”.
The attractions are numerous.
When a database writes to a file system, there is effectively a redirection layer that adds some overhead, and controls where the writes actually go. ASM has no file system overhead and no risk of things like block offsets (where an 8K write could be split across different RAID stripes for instance). It also means that file system acceleration features like readahead (which is often blind to what the application layer is really doing) don’t generate workload Oracle doesn’t need. There is no need for a file system journal and I have heard it said that releasing file system cache can allow more memory to be configured for Oracle SGA (although I am not sure how often that happens).
ASM also writes data across all available logical volumes in the ASM disk group which avoids hot spots. This avoids the need to perform intensive tuning or worry about things like fragmentation of split I/Os. More importantly, it leaves tuning for the most part, totally in the hands of the DBA. As someone who once spent weeks working (as a SAN Storage Guy) on a critical database performance issue caused in the end by bad file system striping, I can attest to the attraction of that!
The other nice advantage is that ASM is available on the all the major Unix and Linux platforms, so if you are a wandering DBA who leaves an AIX or Solaris shop and finds yourself in a Linux shop, you will happily find ASM works in exactly the same way.
Oracle Flash Cache
In a perfect world, there is so much memory available that you can be left giggling at the amount of RAM allocated to each system. In another perfect world, all storage operates at Flash speed and there are no spinning disks at all. But in reality, we are often still constrained by both the quantity of memory available and by disk speed. Being able to use Oracle Database Smart Flash Cache can make a huge difference to read performance and you don’t even need flash storage out in the SAN, you could be using a flash device in your server instead.
When testing new releases you ideally want to be able to still access all these same Oracle features. If Production is using ASM, UAT should ideally also use ASM disk format, and provided your test environment has suitable flash devices (which typically UAT environments do), Flash Cache should be enabled just like it is in production. Also, if production uses Fibre Channel interconnects, seriously consider using the same network topology in your test and dev environments, especially UAT.
Actifio provides an Oracle ASM Solution
Download the ASM Solution Brief Now