When i trying to start oracle db, it says
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/u01/oradata/oracle/system01.dbf'
When I trying to recover using redo logs, i've got
SQL> recover database using backup controlfile;
ORA-00279: change 4925223599 generated at 02/05/2018 10:24:32 needed for thread
1
ORA-00289: suggestion :
/mnt/backup/oracle/ORACLE/archivelog/2018_02_05/o1_mf_1_186975_%u_.arc
ORA-00280: change 4925223599 for thread 1 is in sequence #186975
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/oradata/oracle/redo01.log
ORA-00310: archived log contains sequence 186973; sequence 1
86975 required
ORA-00334: archived log: '/u01/oradata/oracle/redo01.log'
So, in the redo log i only have 186973 sequence. How can i revert all the oracle world to 186973 sequence and forget about next 2 seqs? I need to bring up the db anyhow and some chunk of last data i can lose.
Problem is solved by running
recover automatic database;
Yeah! That simple, thank you all
Related
Recreate control file,this is the code
CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS NOARCHIVELOG
MAXLOGFILES 5
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 '/home/oracle/app/oradata/orcl/redo01.log' SIZE 50M,
GROUP 2 '/home/oracle/app/oradata/orcl/redo02.log' SIZE 50M,
GROUP 3 '/home/oracle/app/oradata/orcl/redo03.log' SIZE 50M
DATAFILE
'/home/oracle/app/oradata/orcl/osc_zb.dbf',
......
CHARACTER SET ZHS16GBK;
After then open database,the result is as follows:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/home/oracle/app/oradata/orcl/system01.dbf'
recover datafile 1:
ORA-00283: recovery session canceled due to errors
ORA-16433: The database must be opened in read/write mode.
then,use hidden parameters to start database.
undo_management='manual'
undo_tablespace='UNDOTBS01'
_allow_resetlogs_corruption=true
also don't work:
SQL> startup pfile=/home/oracle/initoracle.ora
ORACLE instance started.
Total System Global Area 1586708480 bytes
Fixed Size 2253624 bytes
Variable Size 973081800 bytes
Database Buffers 603979776 bytes
Redo Buffers 7393280 bytes
Database mounted.
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/home/oracle/app/oradata/orcl/system01.dbf'
Such a cycle
SQL> recover datafile 1
ORA-00283: recovery session canceled due to errors
ORA-16433: The database must be opened in read/write mode.
I hava no idea to restore database,moguls,help me
Can start to mounted status?Maybe You can try following method。
first,find the 'CURRENT' redo groups.
select group#,sequence#,status,first_time,next_change# from v$log;
And find the redo file location
select * from v$logfile;
Then,through this redo log to recover database
SQL> recover database until cancel using backup controlfile;
ORA-00279: change 4900911271334 generated at 03/06/2018 05:46:29 needed for
thread 1
ORA-00289: suggestion :
/home/wonders/app/wonders/flash_recovery_area/ORCL/archivelog/2018_03_12/o1_mf_1
_4252_%u_.arc
ORA-00280: change 4900911271334 for thread 1 is in sequence #4252
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/home/wonders/app/wonders/oradata/orcl/redo01.log
Log applied.
Media recovery complete.
Finally,open database with ‘RESETLOGS’
Things start not close oracle process when I shutdown system, after I exec startup appear error ORA-01157 ORA-01110.
I very sure dbf file is existed, and I use dbv see the file, every thing is normal.
Last thing, I try offline drop those dbf, but cannot recovery them.
Please give me some help, thank you very much!
mount your database :
SQL> startup mount;
Provided your database is in NOARCHIVELOG mode, Issue the following queries :
SQL> select min(first_change#) min_first_change
from v$log V1 inner join v$logfile f on ( l.group# = f.group# );
SQL> select change# ch_number from v$recover_file;
If the ch_number is greater than the min_first_change of your logs, the datafile can be recovered.
If the ch_number is less than the min_first_change of your logs,
the file cannot be recovered.
In this case;
restore the most recent full backup (and thus lose all changes to
the database since) or recreate the tablespace.
Recover the datafile(If the case in the upper yellow part isn't met):
SQL> recover datafile '/opt/oracle/resource/undotbs02.dbf';
Confirm each of the logs that you are prompted for until you receive the message Media Recovery Complete. If you are prompted for a non-existing
archived log, Oracle probably needs one or more of the online logs to proceed with the recovery. Compare the sequence number referenced in the
ORA-00280 message with the sequence numbers of your online logs. Then enter the full path name of one of the members of the redo group whose sequence
number matches the one you are being asked for. Keep entering online logs as requested until you receive the message Media Recovery Complete .
If the database is at mount point, open it :
SQL> alter database open;
If the DBF file fails to mount then check the source of DBF file, whether it is imported from other database or converted with any other tool. Generally, if the DBF file does not have a specific form then it cannot be mounted, troubleshoot Oracle DBF file by following steps
https://docs.cloud.oracle.com/iaas/Content/File/Troubleshooting/exportpaths.htm
If the database is still causing the problem then there could be problems with other components and before mounting fix them with a professional database recovery tool like https://www.filerepairtools.com/oracle-database-recovery.html
I'm trying to take a dump of a table on to remote disk mounted on my server and below is the cmd I've used.
Exporting of dump started and after 6 hours below ORA errors where thrown.
Looking for a better way:
ORA-02354: error in exporting/importing data
ORA-01555: snapshot too old: rollback segment number 17 with name "_SYSSMU17$" too small
Command used:
expdp user/password TABLES=TABLE_NAME DIRECTORY=TEST_DIR DUMPFILE=DUMP.dmp LOGFILE=LOG.log
My data is stored in Oracle table MY_DATA. This table contains only 2 rows with 7 columns. But when I execute step:
proc sort data=oraclelib.MY_DATA nodupkey out=SORTED_DATA;
by client_number;
run;
the following error appears:
ERROR: The SAS System stopped processing this step because of insufficient memory.
If I comment nodupkey option then error disappears. If I copy dataset in work library and execute proc sort on it then everything is OK too.
My memory options:
SORTSIZE=1073741824
SUMSIZE=0
MAXMEMQUERY=268435456
LOADMEMSIZE=0
MEMSIZE=31565617920
REALMEMSIZE=0
What can be the root of the problem and how can I fix it?
My Oracle password was in grace period and when I changed it the issue disappeared.
I am using Oracle XE 11g R2 and due to a mistake all the archivelogs where deleted by running delete archivelog all; command on RMAN.
Also one set of redo logs were deleted i.e. redo_g02a.log, redo_g02b.log and redo_g02c.log
Other redolog are available i.e. redo_g01a.log, redo_g01b.log, redo_g01c.log and redo_g03a.log, redo_g03b.log and redo_g03c.log
Is there a way I can startup the database now? It is a production database and I am really worried.
I tried copying from redo_g01a.log to redo_g02a.log ... but alert logs say:
ORA-00312: online log 2 thread 1: '/u01/app/oracle/fast_recovery_area/XE/onlinelog/redo_g02a.log'
USER (ospid: 30663): terminating the instance due to error 341
Any help will be much much appreciated.
First make a copy of your datafiles, redo logs, and control file. That way you can get back to this point.
If the database was shut down clean you can try clearing the group and it will be recreated for you.
SQL> connect / as sysdba
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 1068937216 bytes
Fixed Size 2260048 bytes
Variable Size 675283888 bytes
Database Buffers 385875968 bytes
Redo Buffers 5517312 bytes
Database mounted.
SQL> alter database clear logfile group 2;
Database altered.
SQL> alter database open;
Database altered.
SQL>
If not you will need to recover and open with the resetlogs option. Unfortunately because you lost an entire log group you may also have lost data.