Re: ORA-01113_ file 1 needs media recovery
From: ddf <oratune_at_msn.com>
Date: Mon, 27 Apr 2009 07:13:27 -0700 (PDT)
Message-ID: <77ffb3be-72d0-4cf8-a189-413fd5dc513d_at_z23g2000prd.googlegroups.com>
On Apr 26, 10:15 am, Gassamaba <ogs..._at_gmail.com> wrote:
> Hi,
> Please find below an error screenshot. The system failed last week and
> we did recovery from the
>
> tape backup. Initially, there was error Message 4505 then Control_File
> mismatch errors but we
>
> managed to bypass all. Now, the database can be mounted but with this
> error as indicated below.
>
> Is there any possibility to bypass this error/corrupt file so as we
> get access to the database
>
> and generate the dump of data?
>
> ======================screen shot...=-==================
> Alias LISTENER
> Version TNSLSNR for HPUX: Version 2.3.4.0.0 -
> Production
> Start Date 25-APR-09 22:44:45
> Uptime 0 days 0 hr. 0 min. 0 sec
> Trace Level off
> Security OFF
> SNMP OFF
> Listener Parameter File /etc/listener.ora
> Listener Log File /oracle/ora734/network/log/listener.log
> Services Summary...
> e_GA has 1 service handler(s)
> p_GA has 1 service handler(s)
> t_GA has 1 service handler(s)
> The command completed successfully
> ora734_at_ONLINE:/oracle/ora734/dbs>svrmgrl
>
> Oracle Server Manager Release 2.3.4.0.0 - Production
>
> Copyright (c) Oracle Corporation 1994, 1995. All rights reserved.
>
> Oracle7 Server Release 7.3.4.0.0 - Production
> PL/SQL Release 2.3.4.0.0 - Production
>
> SVRMGR> connect internal
> Connected to an idle instance.
> SVRMGR> startup
> ORACLE instance started.
> Total System Global Area 34204208 bytes
> Fixed Size 38984 bytes
> Variable Size 23761384 bytes
> Database Buffers 10240000 bytes
> Redo Buffers 163840 bytes
> Database mounted.
> ORA-01113: file 1 needs media recovery
> ORA-01110: data file 1: '/raid5/BASE/e_GA/SYSTEMe_GA.dbf'
>
>
>
> ========================
>
> Thanks
>
> Gassamaba
Date: Mon, 27 Apr 2009 07:13:27 -0700 (PDT)
Message-ID: <77ffb3be-72d0-4cf8-a189-413fd5dc513d_at_z23g2000prd.googlegroups.com>
On Apr 26, 10:15 am, Gassamaba <ogs..._at_gmail.com> wrote:
> Hi,
> Please find below an error screenshot. The system failed last week and
> we did recovery from the
>
> tape backup. Initially, there was error Message 4505 then Control_File
> mismatch errors but we
>
> managed to bypass all. Now, the database can be mounted but with this
> error as indicated below.
>
> Is there any possibility to bypass this error/corrupt file so as we
> get access to the database
>
> and generate the dump of data?
>
> ======================screen shot...=-==================
> Alias LISTENER
> Version TNSLSNR for HPUX: Version 2.3.4.0.0 -
> Production
> Start Date 25-APR-09 22:44:45
> Uptime 0 days 0 hr. 0 min. 0 sec
> Trace Level off
> Security OFF
> SNMP OFF
> Listener Parameter File /etc/listener.ora
> Listener Log File /oracle/ora734/network/log/listener.log
> Services Summary...
> e_GA has 1 service handler(s)
> p_GA has 1 service handler(s)
> t_GA has 1 service handler(s)
> The command completed successfully
> ora734_at_ONLINE:/oracle/ora734/dbs>svrmgrl
>
> Oracle Server Manager Release 2.3.4.0.0 - Production
>
> Copyright (c) Oracle Corporation 1994, 1995. All rights reserved.
>
> Oracle7 Server Release 7.3.4.0.0 - Production
> PL/SQL Release 2.3.4.0.0 - Production
>
> SVRMGR> connect internal
> Connected to an idle instance.
> SVRMGR> startup
> ORACLE instance started.
> Total System Global Area 34204208 bytes
> Fixed Size 38984 bytes
> Variable Size 23761384 bytes
> Database Buffers 10240000 bytes
> Redo Buffers 163840 bytes
> Database mounted.
> ORA-01113: file 1 needs media recovery
> ORA-01110: data file 1: '/raid5/BASE/e_GA/SYSTEMe_GA.dbf'
>
>
>
> ========================
>
> Thanks
>
> Gassamaba
No, this indicates your SYSTEM tablespace needs recovery and you cannot 'bypass' that as it is the heart of your Oracle database. That you're still running 7.3.4 is a mystery; why haven't you upgraded to a more recent release? Another issue is your statement
> ... Initially, there was error Message 4505 then Control_File
> mismatch errors but we
>
> managed to bypass all. ...
What does that mean, "we managed to bypass all"? Did you correct the source of the errors or did you do something else? Please explain.
David Fitzjarrell Received on Mon Apr 27 2009 - 09:13:27 CDT