Re: Copy Database from NT to W2K

> What you meant 'it's not true ?'. Ok, here the complete story:
>

What he means is that databases working fine under NT port perfectly well to Windows 2000.

> We went to a customer and took his datafiles, incl. control-files,
> init.ora and so on. The customer had NT4, and 7.3.4. Before we left,
> we did a 'alter database backup controlfile to trace' -> x.sql. We
> installed our machine with NT4 and 7.3.3. We patched to 7.3.4, then we
> deleted all the datafiles and put the ones from the customer
> underneath.
>

Not that it should make that much difference, but this sounds a remarkably wacky way of cloning a database. Not entirely sure what "we deleted all the datafiles and put the ones from the customer underneath" actually means, but it sounds like you created a database using Oracle tools first, and then replaced that database's datafiles with your customer's.

What's wrong with using oradim (or oradim73 as I think it would have been then) to create the required service?

> We edited x.sql and changed the new pathes and took the line 'Recover
> database using backup controlfile' out of the script. We started the
> script which ends with 'alter database open resetlogs'. It worked
> under NT4, 7.3.4, great !
>
> We migrated this db all way up to 8.1.7.4 (8.1.6, 8.1.6.1, 8.1.7,
> 8.1.7.1 and finally 8.1.7.4). The DB still worked fine, now with NT4
> and 8.1.7.4. Before we left, we did a 'alter database backup
> controlfile to trace' -> y.sql.
>
> Now we wanted to upgrade the machine to W2K which always failed
> because of a driver for the controller. After several attempts we
> deleted the machine and instead of doing an upgrade we did a new
> installation of W2K. Then we installed Oracle DB 8.1.7 -> 8.1.7.1 ->
> 8.1.7.4. So, at this point we now deleted the new datafiles and wanted
> to put the migrated customer Files underneath.
>
> We did the same thing like at the customer, we started the generated
> y.sql file. The database mounted and tried to open, at this step we
> suddenly got an ora-01092, which we couldn't explain.
>We tried with
> 'recover database until cancel' which didn't help. We had archive logs
> till DEV00049.001, but the system wanted DEV00050.001, which we didn't
> have. The system TS was touched and then the DB crashed.
>

I'm never very sure why all sorts of people start doing weird and wonderful recover commands when things go wrong. It only ever compounds the problem.

> What I suspect is,

You shouldn't have to suspect anything. Learn to read the alert log. It will tell you exactly what state you were in when the instance crashed. And I'll bet you pound to a penny you were in mount state at the time.

>the DB opened and started to make changes, when it
> wanted to write the archive log, it crashed with 1092. We checked all
> the read/write permissions, everything seems ok. I can't explain the
> 1092 otherwise.
>
> Any idea ? In alertlog we had one thing '1534 PRS_0 Rollback.. not
> found', we forgot to take this out of the init.ora, but I don't think
> that this is a problem...
>

I do.

In 9i, you can set UNDO_MANAGEMENT=AUTO, and UNDO_TABLESPACE=BLAH. And if tablespace BLAH doesn't actually exist, you get an ORA-01092 ORACLE instance terminated. Disconnection forced.

I think this is very much the heart of the problem.

But there is so much information missing from your story it is hard to know. How did you take copies of the customer's data files this time? Was it a hot backup? Was the database closed at the time? How do they do their hot backups if the answer to that one was 'it was a hot backup'? What does the ALERT.LOG look like immediately after the instance crashes (and quote it this time, instead of pulling out bits and pieces you think are interesting)?

Ultimately, all I can tell you is: this works. Why it's not working in your case, who can say? You need to diagnose the underlying problem.

Regards
HJR
> I would appreciate every hint and help I can get.
>
> Giuseppe
Received on Mon Dec 23 2002 - 14:46:39 CST