<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: This IBM Storage Fails Too Often, so Let&#8217;s Switch to EMC and Be Done&#8230; NOT!</title>
	<atom:link href="http://www.pythian.com/news/8891/this-ibm-storage-fails-too-often-so-lets-switch-to-emc-and-be-done-not/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.pythian.com/news/8891/this-ibm-storage-fails-too-often-so-lets-switch-to-emc-and-be-done-not/</link>
	<description>News and views from Pythian DBAs</description>
	<lastBuildDate>Fri, 10 Feb 2012 13:01:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Alex Gorbachev</title>
		<link>http://www.pythian.com/news/8891/this-ibm-storage-fails-too-often-so-lets-switch-to-emc-and-be-done-not/#comment-410217</link>
		<dc:creator>Alex Gorbachev</dc:creator>
		<pubDate>Fri, 26 Feb 2010 19:00:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/news/?p=8891#comment-410217</guid>
		<description>@Pete: Good point. I do see the opposite (though, I admit not as often) - DBA&#039;s resist a change and embrace some of the changes. Granted, it&#039;s a job of a DBA to protect the data in the first place but sometimes it taken to absurd levels when DBA team doesn&#039;t want to hear anything about changing their backup strategy (like using some of these cool storage technologies that are licensed and paid for or moving to RMAN from hot backups and etc).

@Alex: thanks for your comments. Totally in line.</description>
		<content:encoded><![CDATA[<p>@Pete: Good point. I do see the opposite (though, I admit not as often) &#8211; DBA&#8217;s resist a change and embrace some of the changes. Granted, it&#8217;s a job of a DBA to protect the data in the first place but sometimes it taken to absurd levels when DBA team doesn&#8217;t want to hear anything about changing their backup strategy (like using some of these cool storage technologies that are licensed and paid for or moving to RMAN from hot backups and etc).</p>
<p>@Alex: thanks for your comments. Totally in line.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alexis Gil Gonzales</title>
		<link>http://www.pythian.com/news/8891/this-ibm-storage-fails-too-often-so-lets-switch-to-emc-and-be-done-not/#comment-410209</link>
		<dc:creator>Alexis Gil Gonzales</dc:creator>
		<pubDate>Fri, 26 Feb 2010 18:36:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/news/?p=8891#comment-410209</guid>
		<description>Unfortunately, many CIOs/Architects either miss or ignore the importance of basic operational processes such as tested recovery plans, and rather take the &quot;important&quot; decisions with their commercial technology vendor contacts: 

- backup solution is provided, but no recovery tests.
- disaster recover solution deployed, no test (we count on our skilled personnel to do the dirty job when &quot;that&quot; happens).
- we have a top-notch NAS solution with &quot;guaranteed&quot; storage reliability.  It&#039;s so good that we&#039;re putting all our critical data on it.  Capacity planning ? We need capacity for DR ? really ?  2 years later data is safe but cannot be restored...
- etc

What seems to me pure raw, crude, basic common sense seems to be completely absent from people who lose contact with the real world while managing large IT budgets.

Life is a song...</description>
		<content:encoded><![CDATA[<p>Unfortunately, many CIOs/Architects either miss or ignore the importance of basic operational processes such as tested recovery plans, and rather take the &#8220;important&#8221; decisions with their commercial technology vendor contacts: </p>
<p>- backup solution is provided, but no recovery tests.<br />
- disaster recover solution deployed, no test (we count on our skilled personnel to do the dirty job when &#8220;that&#8221; happens).<br />
- we have a top-notch NAS solution with &#8220;guaranteed&#8221; storage reliability.  It&#8217;s so good that we&#8217;re putting all our critical data on it.  Capacity planning ? We need capacity for DR ? really ?  2 years later data is safe but cannot be restored&#8230;<br />
- etc</p>
<p>What seems to me pure raw, crude, basic common sense seems to be completely absent from people who lose contact with the real world while managing large IT budgets.</p>
<p>Life is a song&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: PdV</title>
		<link>http://www.pythian.com/news/8891/this-ibm-storage-fails-too-often-so-lets-switch-to-emc-and-be-done-not/#comment-410187</link>
		<dc:creator>PdV</dc:creator>
		<pubDate>Fri, 26 Feb 2010 17:50:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/news/?p=8891#comment-410187</guid>
		<description>Reliability and Operational support (or effecitiveness thereof) are good (well: OK-ish) with most vendors, although there will be small differences.

The real Difference in Results from modern storage now has to come from the Storage Engineers: Can they get the most out of it. Can they make it work for you ?
And why the H-ll does storage have to hide in another silo-department in the IT organisation?

In many situations, the promise of the storage-benefits is never realized because storage engineers are acting as &quot;druids&quot; and fail (#FAIL) to cooperate with sysadmin and DBA.

Storage can be a huge enabler for backups, for test-copies, and to help with DR-implementation. 

But somehow most organistions pay oodles of money to storage(to vendors and to engineers/operators) but still use the System-CPU do run copies and backup.

And when trying to get back a mirror or snap-copy, there is this huge comm-problem between &quot;storage&quot; and &quot;system&quot; and DBA, with sometimes the DBA as the helpless outsider.

Many Storage Departments are now at the stage where DBA&#039;s were in the 1990s: They have beautiful tools with amazing capability, huge promise. But they have to start to communicate with the rest of IT to make their systems work to full potential.

Good Luck!</description>
		<content:encoded><![CDATA[<p>Reliability and Operational support (or effecitiveness thereof) are good (well: OK-ish) with most vendors, although there will be small differences.</p>
<p>The real Difference in Results from modern storage now has to come from the Storage Engineers: Can they get the most out of it. Can they make it work for you ?<br />
And why the H-ll does storage have to hide in another silo-department in the IT organisation?</p>
<p>In many situations, the promise of the storage-benefits is never realized because storage engineers are acting as &#8220;druids&#8221; and fail (#FAIL) to cooperate with sysadmin and DBA.</p>
<p>Storage can be a huge enabler for backups, for test-copies, and to help with DR-implementation. </p>
<p>But somehow most organistions pay oodles of money to storage(to vendors and to engineers/operators) but still use the System-CPU do run copies and backup.</p>
<p>And when trying to get back a mirror or snap-copy, there is this huge comm-problem between &#8220;storage&#8221; and &#8220;system&#8221; and DBA, with sometimes the DBA as the helpless outsider.</p>
<p>Many Storage Departments are now at the stage where DBA&#8217;s were in the 1990s: They have beautiful tools with amazing capability, huge promise. But they have to start to communicate with the rest of IT to make their systems work to full potential.</p>
<p>Good Luck!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

