Oracle 9i Standalone to 10g RAC ??

We have Oracle 9i on Solaris 9 with about 2 TB of data/index on SAN. We want to migrate this to 2 new boxes running Solaris 10 and Oracle 10g RAC -- storage SAN. What should be the best approach (in terms of time & recoverability) considering:
1. Fastest copying method for data/index from existing system (Solaris 9/Oracle 9i -> Solaris 10/Oracle 10g -- all on separate machines).
2. No return to 9i, once it 10g, stay Stanalone and/or RAC.
3. If 10g Standalone to RAC creates problem, stay on 10g Standalone and try later.
4. If ASM creates any issue, stay non-ASM/RAW files and try later.
Who is Participating?

Improve company productivity with a Business Account.Sign Up

mrjoltcolaConnect With a Mentor Commented:
>>Why it's important to know the SAN brand? But as you are asking, let's assume it's EMC's

None of the questions are important if you don't want a serious answer. And just assuming its EMC, does not tell me everything. So "assuming" EMC, do you have Timefinder and BCVs at your disposal?

There are multiple routes you can take, depending on resources and uptime constraints. You really do not want to upgrade your production 9i to a 10g RAC, in case you need to revert back, so you want to leave your production instance untouched.

1) The first thing I would do is proceed with creating an auxiliary copy of your 9i db, and upgrade it to 10g. You will use that copy to migrate to or convert into the target RAC system. The reason I asked about your SAN is because what SAN technology you are using drives what options you have to perform the whole process.  If all systems are using one SAN, you can use BCVs to take a quick 2TB copy, mount it and upgrade that copy to 10g, fairly quickly. That BCV will either need to be converted to a non-BCV volume, or you'll need to migrate the volume. Without BCVs, you'll need to backup & restore using traditional means (hot or cold backup, using RMAN or OS) in order to bring up the auxiliary copy.

2) Second, now that the copy is upgraded to 10g, you can (a) convert the single instance aux copy to RAC or (b) create a 3rd instance, an empty RAC standby and replicate to it with RMAN and/or Data Guard. Since you have the convenience of working against the aux copy, which is low risk, I would simply covert it in place, however, if you are using separate SANs, your volumes must be moved.

So to recap, you have 3 big tasks to accomplish and a 4th optional:
  *) Create an auxiliary (copy) database so as not to risk your 9i production
  *) Upgrade copy to 10g
  *) Migrate copy to RAC (using 2a or 2b)
  *) Optionally migrate RAC to ASM

How you perform each step depends on the specifics I asked for, so I hope you see now why the questions I asmed are important.
Can you be more specific on physical architecture?

1) Describe your SAN (EMC, Netapp, Shark?). Do you have BCV (split mirror) capability?
2) Is this a 24x7 environment?
3) How many servers are at your disposal? (In addition to current Sol 9 and the Sol 10 RAC boxes)
4) How much storage is at your disposal? (In addition to the current Sol 9 storage and Sol 10 RAC storage)

I have not done a migration from version + RAC at the same time, but if you give the requested information I think we can help you formulate a plan.
oracle_9i10gAuthor Commented:
1. Why it's important to know the SAN brand? But as you are asking, let's assume it's EMC's
latest/greatest SAN with tons of Cache & all the LUNs are efficiently striped.
2. Yes but can be taken down for one or two days.
3. Why it's important but if it is, as I mentioned -- 3 top quality SUN boxes with tons of RAM.
4. As much as required -- no limit.
I hope now you can give some answer -- real smart way to migrate efficiently maintaining the options
I mentioned in the original question.
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

oracle_9i10gAuthor Commented:
I am really sorry for my unintentional way of responding to your question -- I do apologize for that but sincerely appreciate your explanation & time. I have some more questions (in this process I can give you some data that may be assumptions because I really don't know that at this time).
Suppose we have 3 Sun machines 1, 2 & 3. #. 1 has Solaris9 9i and #s. 2 & 3 will have Solaris10/RAC.
Case 1:
All sharing the same SAN.
Data/index on cooked file system.
I need to create Aux on #2. Should that be initially 9i and then upgrade to 10g or what?
What is the best tool for copying (assuming BCV is absent) data/index -- OS or RMAN?
Can I have RAW partitions on #2 while its cooked on #1?
Case 2:
#1 and #s. (2 & 3) are on 2 separate SANs.
Same questions as above.
Once I can upgrade to 10g Standalone, I think I know what you are saying but want to make sure this copying is implemented in most secure & fastest way -- please advise once more in this area.
Thanks a lot.

mrjoltcolaConnect With a Mentor Commented:
Hi, I apologize in response, I mistook your response tone. No harm done, thanks for clearing that up. Internet is poor for communicating tone.

I want to qualify everything I say with: I have not migrated cross-platform without export. I've done multi-terabyte migrations, but they were same OS. That said, if you were on Oracle 10g already, then you'd have more options, but you are on 9i, so I'll give you my best opinion based on my experience.

Now that you have clarified that you don't have Timefinder / BCVs in the mix, that narrows it down. I would rather not go through all options in all cases as it gets messy here.

One thing is certain, you have to move to RAW or ASM for RAC. Regardless, you need a raw device or cluster filesystem for the OCR disk for RAC, but the rest can be ASM. You should choose which option first, and go the route that you and your admins are comfortable with. You can move from cooked to either RAW or ASM, but to upgrade 9i to 10g without touching the current primary, the overall approach will be the same, you are going to have to have spare storage and an aux instance with the same Oracle binary version.

I recommend allocating 2TB on the SAN for the aux db, and mount those empty volumes on #2. Install or copy identical Oracle 9i binaries, and setup #2 environment as if you were installing new Oracle. Then, the method you choose to restore will depend on your choice of filesystem. We can do RMAN or low-level UNIX dd command to migrate, however I think RMAN will be required in the ASM case, but I'm not positive.

The goal here is to perform the most critical steps earliest in the process, in case you screw up. So I say, getting the database converted to ASM/RAW on 9i first would be my choice.

After all that, you should have a fully functional 9i AUX database before proceeding to 10g upgrade, and then RAC.

I also recommend you run it by Oracle support to see if they have a recommended migration path for your scenario, because you are mixing 3 steps and this would probably be the most complex migration I've seen without the luxury of using export. I'm an "expert" within reason, but Oracle can tell you a rock solid answer. Metalink also has some howtos and best practices.

If I've not been specific enough feel free to ask for clarification.
oracle_9i10gAuthor Commented:
I sincerely appreciate your time & response. But when you wrote "So I say, getting the database converted to ASM/RAW on 9i first would be my choice." -- sorry to ask, is there any ASM on 9i? I dpn't think so. Anyways, I am closing it and altough your answers didn't answer all my questions - as you are a very nice & really helpful person, I will conside this as solution. Possibly see you in some other thread at a different time.
mrjoltcolaConnect With a Mentor Commented:
Keep the thread open if you like, I will help more.

Yes, ASM is a 10g feature, I wasn't keeping myself honest (sorry been a while since I did much 9i.

The big question is:

1) Do you want to create your auxiliary database to eventually upgrade and convert all the way to 10g RAC.. or
2) do you want to (and have the storage to) use it as a temporary step to get to RAC?

Getting to 10g will give you the ability to convert IN place to ASM, but will require the extra storage anyway, so... maybe just focus on restoring your current cooked fs 9i and upgrading in place to 10g. Then go from there?

All that said, if you REALLY trust your backups,  you could always upgrade the production 9i to 10g in place. How well have you tested them?
Since you have 2TB its really on the cusp of being able to do a full export, though it will be a long one.

You could consider exporting piecewise, schema at a time, table at a time, tablespace at a time, etc. and/or skipping indexes in the export, then you could rebuild the indexes later after the import finishes. (though constraint index definitions will be exported and/or created by default on the import, but the others wont)

Is it possible to do this piecemeal so your exports are manageable?

If so, you can build a 10g RAC from scratch, then do the import and skip all of the other mess.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.