Re: asm on san
From: Michael Austin <maustin_at_firstdbasource.com>
Date: Sun, 14 Dec 2008 13:30:23 -0600
Message-ID: <b9d1l.9924$yr3.4185@nlpi068.nbdc.sbc.com>
>
> Yes, I agree. Unfortunately this is not too good news, because as the
> importance of RAID level decreases, new challenges and potential sources
> for issues arise: network topology, bandwidth, software issues in SAN
> etc. - the whole thing has become significantly more complex than in the
> old days(TM). :-)
>
Date: Sun, 14 Dec 2008 13:30:23 -0600
Message-ID: <b9d1l.9924$yr3.4185@nlpi068.nbdc.sbc.com>
Robert Klemme wrote:
> On 14.12.2008 03:19, Michael Austin wrote:
>> Robert Klemme wrote: >>> On 13.12.2008 23:28, hpuxrac wrote: >>> >>>> In this business you have got to be prepared for the fact that >>>> warm-and-fuzzy only lasts 3-5 years. And if someone doesn't keep up >>>> they fall by the wayside. >>> >>> Switching to the latest and greatest all the time is not an option >>> for everyone. Especially in the area of storage that back 24x7 >>> systems large volume data migration can be difficult to impossible. >>> IMHO understanding of the underlying technologies and how they will >>> scale in a few years from now is important. There are some >>> fundamental issues with RAID 5 that a large cache can only mask. >> >> Yes, that is true, however, with todays technology, they mask it very >> well. And as I stated, the virtualization and obfuscation at the >> array level, including the RAID settings within the array as well as >> stripping within ASM and potentially IBM's SVC front-end, the RAID >> level is *almost* a moot point.
>
> Yes, I agree. Unfortunately this is not too good news, because as the
> importance of RAID level decreases, new challenges and potential sources
> for issues arise: network topology, bandwidth, software issues in SAN
> etc. - the whole thing has become significantly more complex than in the
> old days(TM). :-)
>
What it does mean is that to be an effective DBA, we not only need to understand the database, but the total SYSTEM. Server, OS, SAN, Arrays, Networks, Application development processes and then FINALLY we can actually focus on our job. Keeping the database running efficiently.
As in most environments ANY problem is always the database - until we - the DBA - prove otherwise.
I have said for a LONG time, not just anyone can be a DBA. Received on Sun Dec 14 2008 - 13:30:23 CST