<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: oracle db on SAN (EVA) in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240947#M891137</link>
    <description>&lt;BR /&gt;Like Jean-Luc says, the dbf files already have a given size. Just move (copy) them over and be happy? Or were you planning on a full export - create initial db - import for the move?&lt;BR /&gt;&lt;BR /&gt;&amp;gt; to small will generate alot of files and more waist of space&lt;BR /&gt;&lt;BR /&gt;Nah, too small just give an annoying amount of files to think about, report in statspack and so on. Waste of space is no serious concern.&lt;BR /&gt;&lt;BR /&gt;&amp;gt; To big will slow down the restore procedures&lt;BR /&gt;&lt;BR /&gt;Nah, there is no such thing as 'too big'.&lt;BR /&gt;&lt;BR /&gt;What is your datarate expectation? 50MB/sec? 100MB/sec? if so 4GB will take 40 second, 8GB a minute or two. For many installations that is not significant.&lt;BR /&gt;&lt;BR /&gt;You have to move the data anyway, all of it.&lt;BR /&gt;So whether you have 20 times 2GB or 2 times 20 GB is not going to matter much! It is only a management/scripting issue.&lt;BR /&gt;&lt;BR /&gt;I sometimes keep my dbf files a little smaller (like only 10GB) to be able to copy several in parallel. But with EVA's even that is of minor importance. Since the EVA will engage lots of disks behind a lun, you only need a few concurrent stream to push the IO subsystem to high datarates (like 100MB/sec. We get 350MB per-second-per-EVA for carefully layed out connections).&lt;BR /&gt;At those datarates, a single 10GB file will take 2 minutes or so.&lt;BR /&gt;&lt;BR /&gt;Once you have your EVA's connected I STRONGLY recommend verifying the IO throughput potential. Preferably with a dedicated tool (HP internally we use diskbench, and dt), be a couple of dd scripts will do the job too.&lt;BR /&gt;&lt;BR /&gt;hth,&lt;BR /&gt;Hein.&lt;BR /&gt;</description>
    <pubDate>Tue, 06 Apr 2004 09:43:45 GMT</pubDate>
    <dc:creator>Hein van den Heuvel</dc:creator>
    <dc:date>2004-04-06T09:43:45Z</dc:date>
    <item>
      <title>oracle db on SAN (EVA)</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240943#M891133</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;we are going to move all our databases to a EVA SAN from HP. Today all databases are running on direct attached disksystem. When we move the databases to the SAN, what filesize on the databasefiles are most appropriate? I guess to small will generate alot of files and more waist of space. To big will slow down the restore procedures. Is 4 GB appropriate or is 8 GB appropriate. Any suggestions? Pros and cons? Our biggest database is 350 GB. It will be running on HP-UX 11i on Risc processors.</description>
      <pubDate>Tue, 06 Apr 2004 06:05:26 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240943#M891133</guid>
      <dc:creator>Morten Kristiansen</dc:creator>
      <dc:date>2004-04-06T06:05:26Z</dc:date>
    </item>
    <item>
      <title>Re: oracle db on SAN (EVA)</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240944#M891134</link>
      <description>almost of my dbfile size is 3GB.&lt;BR /&gt;what is the most performance boost up is try to minimize full table scan.&lt;BR /&gt;</description>
      <pubDate>Tue, 06 Apr 2004 06:10:56 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240944#M891134</guid>
      <dc:creator>Printaporn_1</dc:creator>
      <dc:date>2004-04-06T06:10:56Z</dc:date>
    </item>
    <item>
      <title>Re: oracle db on SAN (EVA)</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240945#M891135</link>
      <description>If the databases exist already on direct attached disksystem, you will move to the SAN and this won't change their size !&lt;BR /&gt;I suppose you're talking about future databases ?&lt;BR /&gt;A SAN should improve IO as you have "some" read and write cache. I you can have it go for RAID0+1 instead of RAID5.&lt;BR /&gt;&lt;BR /&gt;What kind of backup utility do you use ?&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;Jean-Luc</description>
      <pubDate>Tue, 06 Apr 2004 09:00:51 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240945#M891135</guid>
      <dc:creator>Jean-Luc Oudart</dc:creator>
      <dc:date>2004-04-06T09:00:51Z</dc:date>
    </item>
    <item>
      <title>Re: oracle db on SAN (EVA)</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240946#M891136</link>
      <description>Hello&lt;BR /&gt;&lt;BR /&gt;Our policy is 5 Go per DBF (on an EMC DMX200 SAN.)&lt;BR /&gt;&lt;BR /&gt;The db block size and OS size have been subject to various discution and documentation. As for the size of the datafiles, is there any Oracle recommandation on that ?&lt;BR /&gt;&lt;BR /&gt;Since the IO load is spread on various disks, with the abstration layer of the volume manager product, does it really matter ?&lt;BR /&gt;&lt;BR /&gt;The maxime filesize on HP with Oracle Block size of 8k, is 4194303 * 8k = 34gigs. &lt;BR /&gt;&lt;BR /&gt;Filesize Limits for HPUX (Note:62407.1)&lt;BR /&gt;&lt;BR /&gt;Cheers&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Tue, 06 Apr 2004 09:19:48 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240946#M891136</guid>
      <dc:creator>Nicolas Dumeige</dc:creator>
      <dc:date>2004-04-06T09:19:48Z</dc:date>
    </item>
    <item>
      <title>Re: oracle db on SAN (EVA)</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240947#M891137</link>
      <description>&lt;BR /&gt;Like Jean-Luc says, the dbf files already have a given size. Just move (copy) them over and be happy? Or were you planning on a full export - create initial db - import for the move?&lt;BR /&gt;&lt;BR /&gt;&amp;gt; to small will generate alot of files and more waist of space&lt;BR /&gt;&lt;BR /&gt;Nah, too small just give an annoying amount of files to think about, report in statspack and so on. Waste of space is no serious concern.&lt;BR /&gt;&lt;BR /&gt;&amp;gt; To big will slow down the restore procedures&lt;BR /&gt;&lt;BR /&gt;Nah, there is no such thing as 'too big'.&lt;BR /&gt;&lt;BR /&gt;What is your datarate expectation? 50MB/sec? 100MB/sec? if so 4GB will take 40 second, 8GB a minute or two. For many installations that is not significant.&lt;BR /&gt;&lt;BR /&gt;You have to move the data anyway, all of it.&lt;BR /&gt;So whether you have 20 times 2GB or 2 times 20 GB is not going to matter much! It is only a management/scripting issue.&lt;BR /&gt;&lt;BR /&gt;I sometimes keep my dbf files a little smaller (like only 10GB) to be able to copy several in parallel. But with EVA's even that is of minor importance. Since the EVA will engage lots of disks behind a lun, you only need a few concurrent stream to push the IO subsystem to high datarates (like 100MB/sec. We get 350MB per-second-per-EVA for carefully layed out connections).&lt;BR /&gt;At those datarates, a single 10GB file will take 2 minutes or so.&lt;BR /&gt;&lt;BR /&gt;Once you have your EVA's connected I STRONGLY recommend verifying the IO throughput potential. Preferably with a dedicated tool (HP internally we use diskbench, and dt), be a couple of dd scripts will do the job too.&lt;BR /&gt;&lt;BR /&gt;hth,&lt;BR /&gt;Hein.&lt;BR /&gt;</description>
      <pubDate>Tue, 06 Apr 2004 09:43:45 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240947#M891137</guid>
      <dc:creator>Hein van den Heuvel</dc:creator>
      <dc:date>2004-04-06T09:43:45Z</dc:date>
    </item>
    <item>
      <title>Re: oracle db on SAN (EVA)</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240948#M891138</link>
      <description>Sorry guys, forgot to tell you that we are moving from a tru64 platform using advanced FS, to a HP-UX platform using Veritas FS. So copying the database files is no issue. It have to be done by export/import. We are using RMAN backup utilities together with Legato.</description>
      <pubDate>Tue, 06 Apr 2004 23:39:23 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240948#M891138</guid>
      <dc:creator>Morten Kristiansen</dc:creator>
      <dc:date>2004-04-06T23:39:23Z</dc:date>
    </item>
    <item>
      <title>Re: oracle db on SAN (EVA)</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240949#M891139</link>
      <description>Morten,&lt;BR /&gt;I am interested to learn to what extent HP is involved with the migration. Did the customer request help? Did HP propose? Are they ssing a service/consultancy or the regular DBA(s) and SSys Admin(s)? Time window? Test runs? Things along those lines.&lt;BR /&gt;&lt;BR /&gt;I'd much appreciate a short Email to me. Mostly out of personal curiosity, and a little because I sit next to, and occasionally work with, folks that facilitate migrations.&lt;BR /&gt;&lt;BR /&gt;Thanks!&lt;BR /&gt;hein at hp dot com.&lt;BR /&gt;</description>
      <pubDate>Wed, 07 Apr 2004 00:14:04 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240949#M891139</guid>
      <dc:creator>Hein van den Heuvel</dc:creator>
      <dc:date>2004-04-07T00:14:04Z</dc:date>
    </item>
    <item>
      <title>Re: oracle db on SAN (EVA)</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240950#M891140</link>
      <description>Hi!&lt;BR /&gt;&lt;BR /&gt;Does the EVA provide u fibre connectivity or is it SCSI?&lt;BR /&gt;If its fibre i dont think u should bother abt the speed as i have mostly 5GB datafiles and the read write is superb.&lt;BR /&gt;&lt;BR /&gt;Regards.</description>
      <pubDate>Wed, 07 Apr 2004 03:15:32 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240950#M891140</guid>
      <dc:creator>Syed Shaffat Ali</dc:creator>
      <dc:date>2004-04-07T03:15:32Z</dc:date>
    </item>
    <item>
      <title>Re: oracle db on SAN (EVA)</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240951#M891141</link>
      <description>The EVA typically has 4 Fibre connections, and as I wrote before can deliver 350+ MB/sec when there is enough concurrent activity and they those 4 connections are all in use.&lt;BR /&gt;Thise max throughput requires a minimum of 2 HBAs in your servers and clever zoning / device selection to spread the load over the HBA's.&lt;BR /&gt;&lt;BR /&gt;Hein.</description>
      <pubDate>Wed, 07 Apr 2004 07:22:46 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-db-on-san-eva/m-p/3240951#M891141</guid>
      <dc:creator>Hein van den Heuvel</dc:creator>
      <dc:date>2004-04-07T07:22:46Z</dc:date>
    </item>
  </channel>
</rss>

