02-29-2012 09:50 AM
Has anybody had any experience of the Oracle upgrade required for this - ? I have the 2 boxes - DS20E and Rx2800i sharing data across the network ready for the migrate to start - I presume a need a new version of Oracle10g to run on the Integrity server as the 1st stage. Thanks
02-29-2012 09:57 AM
02-29-2012 11:53 AM - edited 02-29-2012 11:54 AM
Yes, this migration is possible, and yes, you'll need the Integrity software installation kits and the necessary licenses from Oracle.
Check the Oracle database documentation for details of the migration. One of the simplest approaches (and given this configuration is probably not clustered), this will be a database export from the OpenVMS Alpha environment , transfer the export file via ftp, DECnet or via removable disk, and then followed by a database import within the OpenVMS I64 environment.
02-29-2012 01:30 PM
The code will be different, the data exactly the same.
First you'll need to install Oracle on the Itanium.
You should be licensed, but no physical license is needed.
Next you MUST apply the latest patch kit. Don't put that off.
You must have a support contract to get/download the patch kit.
Now comes the data. You can transfer raw datafiles (Copy, ftp, nfs, whatever...) and use those.
Most likely you want to create a shell database, export on Alpha (datapump!?) and import in the Itanium.
The information is much more dense, specially if you zip it up.
You may consider clustering the systems to facilitate data transfer.
Where is the database on the DS20?
Internal drives? If it is on attached storage you can possibly 'plug' over the storage, point to it, and go!
03-01-2012 02:38 AM
the data on the DS20 is on a MSA1000 Array - I have successfully FTP'd all the database files across to the RX2800i + D2700 rack.
Will get in touch with Oracle and get all the relevant software
will keep you posted of progress
03-01-2012 07:04 AM - edited 03-01-2012 07:07 AM
Since the data is on an MSA you could potentially make it directly accessible by the new Itanium if that has, or can be given, a Fibrechannel adapter card.
Not worried about those transferred files being stale now or is this a dry run? That would make sense.
You know what they say: Might as well plan on throwing one away, because you will.
Or do you have a plan to apply archive logs/redo to bring it up to date eventually?
Was the source DB properly closed when you transferred?
While it is certainly feasible to figure all of this out from the (excellent!) Oracle documentation, and the many topics on this subject accross many forums it will consume a lot of time.
You may want to engage a consultant/contractor who has experience in this area.
Also, 95% off this challenge is Oracle related, 5% OpenVMS
03-02-2012 02:52 AM
Yes this is a test run - just putting together the migration plan and will be testing over a few weeks - the LIVE migrate will be over a weekend.
Many Pro Fortran, Pro C programs to recompile as well.
We have done this sort of thing before with previous upgrades to Oracle/VMS on Alpha but never across Alpha to Integrity.
On ths MSA1000 yes we do have a fibre optic card in the RX2800 which we could configure - however happy to go with FTP as the transfer mechanism - total time for transfer of Database files is only 5 hours - so can live with that for a weekend migrate.
03-02-2012 03:09 AM
On a slightly different point can anyone explain why looking at files on the Alpha DS20E I see min file size of 205 blocks but on the Integrity RX2800 i see min size of 1104 blocks? This is after a restore of .bck save set which was FTp'd across servers.
Both disk are ODS-5
03-02-2012 03:49 AM
03-02-2012 04:36 AM
Thanks Dan and Duncan - Understood - it is about a 5 fold increase in disk space between systems which relates to the min file size
03-02-2012 08:04 AM
>> it is about a 5 fold increase in disk space between systems
So now that you know... fix it before going live.
Seem you had a cluster size of 205, now it defaulted to 1104
The default is roughly disk size divided by a million.
But you can just do: $ INIT /CLUST=256 /STRUCT=5 ...
I like powers of 2 for my cluster sizes.
Since you had 205, 256 is probably fine.
If you anticipate hundreds of thousands of file, you many trim it down to 32 or so.
If you anticipate less than thousand files, say Oracle database files, then go for 1024 or 4096 or some such.
If there are conflicting requirements, then you may want to consider using the storage tools to generate multiple, smaller volumes/partitions.
Or, you could use the LDdriver to create one or two smaller virtual drives on the large volume to hold many small files with cluster size (on the LD volume of 8 or 16)