back to the SAN
yeah, I should have done this a long time ago.
Unfortunately, been busy as heck with a Peoplesoft upgrade that somehow degenerated into installing and setting up two additional servers and a load balancer with the usual plethora of problems, compatibility glitches, version clashes, appserver performance issues, etcetc...
Had to put my foot down and explain very clearly that my field is databases and data management and none of the above has anything to do with what I'm trained to do! Some people have difficulty in understanding this.
I also have a problem with project "plans" that get ammended every day. Frankly, that's not a plan: that's a diary!...
But, I digress...
Kevin blogged recently for a while on SANs and NAS/NFS and their many relationships and uses with database servers.
Apparently, it all started with a comment I made here a while ago about how easy it is to reconfigure a storage facility with a SAN.
Some folks assumed I was in some form criticizing Kevin's many interventions on NAS/NFS and its advantages compared to SANs in the database server universe.
Now, let me be very clear about this: in the last few years I've been discussing storage technologies and exchanging opinions with Kevin through the oracle-l list first and later through the blogsphere - and many times through email which he's always been gracious to reply to - and I have yet to see one instance where we disagree in a major way.
Sure: our experiences in the storage area may be slightly different in many cases and that certainly explains some of our small differences of opinion. But by and large, I can state that if I ever get stuck with an I/O capacity problem, I need only one person helping me and that is Kevin.
He knows his I/O in detail and in depth and I agree with almost every single one of his well researched and accurate statements and opinions. As anyone following some of my replies in his blog would probably have found out by now.
As such, it was with surprise I sensed folks thought my comment a while ago was in some form derogatory or disparaging of anything he had said.
Let me be very clear: that was most certainly not my intention!
What I may have failed to explain back then is that I tend to prefer SANs for our environment for one major reason: we run a mixed shop with many, many SQL Server and Lotus Notes servers as well as our Oracle dbs. And multiple Wintel file servers and Citrix nodes which all end up needing disk space in some form or other.
In such an environment, it is hard - at this stage of the technology! - to integrate a single NAS service solution.
SANs have been around longer and make these mixed environments easier to configure than for example with server native disks.
They also allow for flexible mixes of the Wintel and Unix universes - in our case AIX and Solaris. "flexible" in that we can easily reconfigure the IO setup between all this cacophony of sometimes conflicting demands for storage.
Moving on:
At the moment we are far from being I/O constrained in the Oracle servers. But if that ever happens, my next port of call will surely be add-on NAS/NFS technology.
And here enters the determining factor in all these musings: "suitability and integration of a technology, within budgetary constraints". Something that is closely related to the often quoted "real life", although I do hesitate in using that old chestnut.
Of course dedicated disks and their respective controllers in a db server, in sufficient quantities, provide the absolute best speed and overall performance. Why else would the TPC folks use them if that was not the case?
The question being: do I have a need for that level of performance within the overall constraints of my budget and environment? Or perhaps more importantly: does my site NEED that level of performance right now?
If so, then there is no question: I have to use that technology. But if not, then other solutions might be more appropriate in their cost effectiveness.
The next one down from native disks in my list of performance preference would definitely be a NAS setup like the ones Kevin talks about. Particularly if I am running a Linux environment. The advantages have already been touched on by him and I won't dwell on that now.
The last solution for me in terms of speed/performance is the SAN. It's also the most flexible when dealing with mixed environments. And in our case at the moment, that is the major factor in a decision about storage technology. So we use a SAN setup. But it is important to understand why.
This is not to say we won't add to it, at some stage, a NAS facility! In fact it is likely we may do so in the next couple of years, as our DW continues to grow and it becomes cheaper to just store the lot than to fight over archival processes.
But that's another battle, for another blog...
Now folks: do yourselves a favour and go read Kevin's blog on configuring lgwr and dbwr in your Oracle databases. Trust me: take a nice long time at it and ask questions on anything you find harder to understand. It's worth it.
Catchyalata, folks!
Unfortunately, been busy as heck with a Peoplesoft upgrade that somehow degenerated into installing and setting up two additional servers and a load balancer with the usual plethora of problems, compatibility glitches, version clashes, appserver performance issues, etcetc...
Had to put my foot down and explain very clearly that my field is databases and data management and none of the above has anything to do with what I'm trained to do! Some people have difficulty in understanding this.
I also have a problem with project "plans" that get ammended every day. Frankly, that's not a plan: that's a diary!...
But, I digress...
Kevin blogged recently for a while on SANs and NAS/NFS and their many relationships and uses with database servers.
Apparently, it all started with a comment I made here a while ago about how easy it is to reconfigure a storage facility with a SAN.
Some folks assumed I was in some form criticizing Kevin's many interventions on NAS/NFS and its advantages compared to SANs in the database server universe.
Now, let me be very clear about this: in the last few years I've been discussing storage technologies and exchanging opinions with Kevin through the oracle-l list first and later through the blogsphere - and many times through email which he's always been gracious to reply to - and I have yet to see one instance where we disagree in a major way.
Sure: our experiences in the storage area may be slightly different in many cases and that certainly explains some of our small differences of opinion. But by and large, I can state that if I ever get stuck with an I/O capacity problem, I need only one person helping me and that is Kevin.
He knows his I/O in detail and in depth and I agree with almost every single one of his well researched and accurate statements and opinions. As anyone following some of my replies in his blog would probably have found out by now.
As such, it was with surprise I sensed folks thought my comment a while ago was in some form derogatory or disparaging of anything he had said.
Let me be very clear: that was most certainly not my intention!
What I may have failed to explain back then is that I tend to prefer SANs for our environment for one major reason: we run a mixed shop with many, many SQL Server and Lotus Notes servers as well as our Oracle dbs. And multiple Wintel file servers and Citrix nodes which all end up needing disk space in some form or other.
In such an environment, it is hard - at this stage of the technology! - to integrate a single NAS service solution.
SANs have been around longer and make these mixed environments easier to configure than for example with server native disks.
They also allow for flexible mixes of the Wintel and Unix universes - in our case AIX and Solaris. "flexible" in that we can easily reconfigure the IO setup between all this cacophony of sometimes conflicting demands for storage.
Moving on:
At the moment we are far from being I/O constrained in the Oracle servers. But if that ever happens, my next port of call will surely be add-on NAS/NFS technology.
And here enters the determining factor in all these musings: "suitability and integration of a technology, within budgetary constraints". Something that is closely related to the often quoted "real life", although I do hesitate in using that old chestnut.
Of course dedicated disks and their respective controllers in a db server, in sufficient quantities, provide the absolute best speed and overall performance. Why else would the TPC folks use them if that was not the case?
The question being: do I have a need for that level of performance within the overall constraints of my budget and environment? Or perhaps more importantly: does my site NEED that level of performance right now?
If so, then there is no question: I have to use that technology. But if not, then other solutions might be more appropriate in their cost effectiveness.
The next one down from native disks in my list of performance preference would definitely be a NAS setup like the ones Kevin talks about. Particularly if I am running a Linux environment. The advantages have already been touched on by him and I won't dwell on that now.
The last solution for me in terms of speed/performance is the SAN. It's also the most flexible when dealing with mixed environments. And in our case at the moment, that is the major factor in a decision about storage technology. So we use a SAN setup. But it is important to understand why.
This is not to say we won't add to it, at some stage, a NAS facility! In fact it is likely we may do so in the next couple of years, as our DW continues to grow and it becomes cheaper to just store the lot than to fight over archival processes.
But that's another battle, for another blog...
Now folks: do yourselves a favour and go read Kevin's blog on configuring lgwr and dbwr in your Oracle databases. Trust me: take a nice long time at it and ask questions on anything you find harder to understand. It's worth it.
Catchyalata, folks!
posted by Noons at 8/29/2007 12:11:00 am
2 Comments:
HiYa
was reading this nodding then noticed a reference to some pictures. Gone?
oh well
Sorry. They were linked in from another place, rather than loaded into Blogger. When I cleaned up, they went...
Most are in my photo site at deviantart anyways.
Post a Comment
<< Home