OK, well thanks for the reply.. but I have no idea how to perform the CONNECT INTERNAL command, since you said SQL Plus is something I should NOT be using. I can find a 'svrmgrl' anywhere, what is this?
Main Topics
Browse All TopicsFirst off, I know very very little about Oracle, so please be detailed in your explanations and consider the versions of tools I am using.
This is all on an Oracle 7.3.2.3.1 Database that is running on an NT4 server.
I have access to the following tools:
Oracle Enterprise Manager 1.3.6
SQL*Plus 3.3.4.0.0
I created several new datafiles (all set at 2gb in size) because I have to upload a bunch of new data to this DB, but one was created in the wrong location. So I 'tried' to take that datafile 'offline' but it stated STATUS as RECOVER.
So in Storage Manager I highlighted the Tablespace, that contains this datafile, on the left pane. This showed me the list of all datafiles within this tablespace, so I highlighted the datafile in question (FIL11ORCL.ORA) and chose the 'Offline' option above, and this inadvertantly took the whole tablespace offline. So now ALL of the datafiles status show as RECOVER.
I try to bring the tablespace back online and get the following errors:
ORA-01113: file 7 needs media recovery
ORA-01110: data file 7: 'D:\DOC_DATA\FIL1ORCL.ORA'
I've searched here on EE, and have found several things that I thought might work and some of the commands just don't work with my SQL Plus, or because my DB is 7.3?
For instance the RECOVER command returns 'unknown command'.
I'm completely lost, and in big trouble if I can't get this thing back up and running by Monday morning. They tossed this ancient DB in my lap because I have 'some' db experience, and now my 'experience' has gotten me into a pickle.
Any and ALL help will be greatly appreciated.
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
I coudn't find the 'svrmgrl' anywhere, but did just find a 'svrmgr23' in the ORANT\BIN directory..
OK, so now I'm connected to the DB with svrmgr23, and am not sure how to attempt recovery... since the syntax that HELP gave me for the CONNECT command was NOT how I actually got connected after many tries, I'm scared to attempt the recovery command with the syntax it gives me, I don't want to hurt the DB any more than I all ready have.
Can you give me the EXACT syntax I need to type to recover 'F:\ORANT\NightlyBackups\F
again, TIA.
Yes, the tool you need for Oracle 7.3 is svrmgr23. The "connect" syntax is very simple: "connect internal". That will most likely succeed without prompting you for a password. If it does prompt you for a password, you will need the password for the SYS account. What I would suggest before you do anything else is "shutdown immediate", then exit Server Manager and take a cold backup. To do that, stop the service: OracleService[SID] then simply copy all of the datafiles, the on-line redo log files and the control file(s) to alternate disks. This will allow you to at least get back to the current point, if you have a problem.
After that, start the service, then restart Server Manager (svrmgr23) and type "connect internal". I recommend that you then do: "startup mount". (If it says something like "instance or database already started or running", then do "shutdown immediate", then "startup mount"). This will put the database in a special "maintenance" mode where it is not open for normal use, but will allow you to move a datafile. To move a datafile, just use a DOS or Windows copy command to put it where you want it, then from Server Manager do:
alter database rename file '[old_path\file_name]' to '[new_path\file_name]';
With the database in that state, you should also be able to recover any files that need it. With newer versions of Oracle (I'm not sure if this works with Oracle7.3 or not - it's been eight years since I've seen that version) you can simply do: "recover database" or "alter database recover" and Oracle will automatically recover any/all datafiles that need media recovery.
You may need syntax like: "alter database recover datafile '[path_and_name_of_datafil
If that succeeds, you simply then do:
alter database open;
If that succeeds, I would recommend that you then do:
shutdown immediate;
and take another backup, then do a normal startup.
markgeer,
I appreciate the detailed response.. I have been playing with the DB for a few hours now, so I have made 'some' progress.
I somehow managed to get the tablespace back up and running, and all datafiles 'recovered' and were ONLINE. I tested the application that uses this DB/Tablespace, and everything seems(ed) good. So I then attempted a few more things to try and move that datafile that I created in the wrong location, and am now back to where I was just before I shutdown the tablespace by accident this morning.
Right now the tablespace is running, and all datafiles EXCEPT the one I want to move are ONLINE. The one I want to move, I tried to turn OFFLINE within Storage Manager. This resulted in it showing STATUS of RECOVER.
So, I was going to try the methods you described above, and I apparently have insufficient privileges to SHUTDOWN IMMEDIATE (I imagine this shuts down the entire DB and not just any specific tablespace since there was no tablespace specified in the command?)
My login does seem to have 'most' rights over the Tablespace I need to move the datafile for, so is there another method other than doing the SHUTDOWN IMMEDIATE to gain this ability to REANME FILE ?
Again thanks so much for the help, I feel I'm almost there.
Having the database running again is a good thing! If there is nothing (or at least nothing important) in that tablespace yet, it may be may be simpler to drop it and recreate it where you want. But I just remembered that may be complex in Oracle7.3. In Oracle8.0 and higher, you can do "drop tablespace [tablespace_name] including contents;" but Oracle7.3 does not support that syntax if I remember correctly, and it may not let you drop a tablespace that is not empty.
Yes, a "shutdown immediate;" does a complete database shutdown. If you used svrmgr23, and did "connect internal", that would give you maximum privileges, including the ability to shutdown and/or startup the database as well as rename (move) a datafile - if the database and/or datafile/tablespace are at a status that allows that.
Usually when I move a datafile, I have the database shutdown, and then do a "startup mount" but I think it is possible to take a particular tablespace offline, then move it (with two steps: an O/S file copy, then in Oracle "alter database rename datafile '[old_location\name]' to '[new_location\name]';)
So it sounds like there is no other way to rename/move the datafile without being local on the Oracle server? As I'm assuming that's the only way the 'connect INTERNAL' will work, since it doesn't work for me remotely. I have to log in with a user account via the CONNECT command. And again, it said I didn't have sufficient privileges to perform the shutdown.
Well, for the most part it does seem to be working, and this tablespace DOES contain A LOT of data, so there is no way I'm attempting to 'drop' any tables.. Perhaps I'll have to wait until Monday to get better access to the server and just hope nothing pukes completely in the interum due to that one datafile in 'RECOVER' mode..
Any other suggestions?
Right, you will have to be local to the server, or use remote control software like pcAnywhere or Sunbelt Remote Administrator (I use that for an NT4 / Oracle8.1 server I still manage).
Yes, the database should be fine with one datafile in 'RECOVER" status, and as long as no one or no process tries to use the contents of that file, no one will notice.
I appreciate all of the help. I actually have VNC to get into this server, but the host keeps crashing on me, so once I have that addressed on Monday, I should be able to perform the tasks you noted above, and hopefully that will all work out for me.
I'll leave this open until then, and if all goes well, you'll have a bucket of points comin your way.
thanks again.
Business Accounts
Answer for Membership
by: angelIIIPosted on 2005-08-13 at 09:34:12ID: 14667762
in Oracle 7.3, the database/instance operations where not to be performed using sqlplus, but svrmgrl.
to try to perform the RECOVER DATABASE using that command line tool.
to start svrmgrl, ensure the oracle variables are all set (ORACLE_SID, ORACLE_HOME and PATH including the $ORACLE_HOME/bin).
to connect, use the command CONNECT INTERNAL;
Hope this helps already to take the first steps.