I have an oracle database which has problems preventing it from opening.
To overcome the issues, I tried following steps:
First I mounted database:
SQL> startup mount;
ORA-32004: obsolete and/or deprecated parameter(s) specified
ORACLE instance started.
Total System Global Area 1.2560E+10 bytes
Fixed Size 2171344 bytes
Variable Size 6878662192 bytes
Database Buffers 5670699008 bytes
Redo Buffers 8601600 bytes
Database mounted.
After that, I recovered database as below:
SQL> recover database until cancel;
ORA-00279: change 338584095 generated at 11/22/2016 08:41:55 needed for thread 1
ORA-00289: suggestion : /oracle/app/product/11g/db/dbs/arch1_9218_833801667.dbf
ORA-00280: change 338584095 for thread 1 is in sequence #9218
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oracle/app/oradata/ora11g/system01.dbf'
ORA-01112: media recovery not started
After this I tried to alter open database as below:
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oracle/app/oradata/ora11g/system01.dbf'
and finally I tried recovering system01 datafile as below:
SQL> recover datafile 1;
ORA-00283: recovery session canceled due to errors
ORA-00314: log 2 of thread 1, expected sequence# 9218 doesn't match 9215
ORA-00312: online log 2 thread 1: '/oracle/app/oradata/ora11g/redo02.log'
as you can see in the final error "ORA-00314: log 2 of thread 1, expected sequence# 9218 doesn't match 9215" there is a sequence mismatch between the logfile redo02.log and the server.
How can this mismatch occur and what can I do to fix this?
PS: Since database cannot be opened, I cannot switch logfile and since redo02.log is the current logfile, I cannot drop or clean it.
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- ------------------
1 1 0 52428800 1 NO UNUSED
338564041 22-NOV-16
3 1 0 52428800 1 NO UNUSED
338544000 22-NOV-16
2 1 9218 52428800 1 NO CURRENT
338584094 22-NOV-16
Related
My extract process is not running, below is the errors found, kindly suggest how to get all process up and running.
GGSCI (pltv015) 3> info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
EXTRACT ABENDED EXTEMP 00:00:04 05:46:53
EXTRACT RUNNING PUMPEMP 00:00:00 00:00:03
REPLICAT STOPPED REP507 00:00:00 00:18:08
REPLICAT ABENDED REPTEST 00:00:00 2527:29:44
for EXTEMP :
2020-07-31 06:59:39 ERROR OGG-06601 Mismatch between the length of seqno from checkpoint (9) and recovery (6) for extract trail /opt/app/t1c2d507/ggs/t1c2d507/tr
ails/p1
for REP507 ::
2020-07-31 06:59:37 ERROR OGG-00664 OCI Error beginning session (status = 1017-ORA-01017: invalid username/password; logon denied).
2020-07-31 06:59:37 ERROR OGG-01668 PROCESS ABENDING.
2020-07-31 06:59:39 ERROR OGG-06601 Oracle GoldenGate Capture for Oracle, extemp.prm: Mismatch between the length of seqno
from checkpoint (9) and recovery (6) for extract trail /opt/app/t1c2d507/ggs/t1c2d507/trails/p1.
Just in case it might help you. The following workaround applies only to Oracle GoldenGate version 12.2.0.1.0. Applies to any to any platform.
Running GG version 12.2 PUMP fails with this error
ERROR OGG-06601 Mismatch between the length of seqno from checkpoint (9) and recovery (6) for extract trail /path_to_the_trail/
Trying to read trail file which uses 6 digit checkpoint with version 12.2 when this version uses a 9 digit checkpoint. Same error might happen even when the trail files are actually having the same length as well. In that case, the error message is incorrect as it is related with a bug with code 25439681.
If the error "Mismatch between the length of seqno from checkpoint (9) and
recovery (6) for extract trail" is seen and the filename lengths are the same
then this bug may have been encountered. Note that this message masks the
real error message so the fix in Bug 25439681 does not resolve the underlying error but
makes sure the correct error is reported.
Workaround
PART I
Stop PUMP
Stop Manager
Add the following to your GLOBALS file
TRAIL_SEQLEN_6D
REASON: Tell GG to use 6 digit checkpoint
Start Manager
Alter Pump with ETROLLOVER
Start Pump
Allow PUMP to read local trail file and write them to a remote trail file
Allow replicat to process all transactions. Replicat should show 0 lags to indicate all transactions , from the source, have been processed on the target database.
REASON: Clean up existing trail files, created from a prior release to GG version 12.2, still using a 6 digit checkpoint
PART II
Assuming you had no problems with PART I, then you need to perform some tasks both in source and target.
On Source
Remove TRAIL_SEQLEN_6D from GLOBALS
alter ext E1 etrollover where E1 is the name of your extract which creates the local trail file. REASON: ETROLLOVER needed to convert 6 digit checkpoint to 9 digits as well as GG version 12.2
Use the following to display the new sequence number of local trail file.
info extract E1, detail
or
info extract E1, showch
Write Checkpoint #1
Current Checkpoint (current write position):
Sequence #: xx
where xx = new sequence number of local trail file
alter ext P1, extseqno xx , extrba 0 (where xx = new sequence number of local trail file and P1 is the name of your PUMP) --> to handle input trail and the REASON: Tell PUMP to use the new local trail file created in step 1
alter ext p1, etrollover ---> to handle output trail. Reason Tell PUMP to create and write to a new remote trail file.
Use the following to display the new sequence number of the remote trail file
info extract E1, detail
or
info extract E1, showch
Write Checkpoint #1
Current Checkpoint (current write position):
Sequence #: yy
where yy = new sequence number of the remote trail file
On Target
alter replicat R1, extseqno yy , extrba 0 where yy = new sequence number + 1 of the remote trail file
Go back to Source
Allow changes to be made to Source tables involved with GG
Perform insert or update to verify it gets replicated to the target.
UPDATE
To update the password of the CGADMIN
Step 1: check Golden Gate user
SQL> select username,account_status from dba_users where username like ‘GG%’;
USERNAME ACCOUNT_STATUS
—————————— ——————————–
GGADMIN OPEN
Step 2: Change the password is database first
SQL> alter user GGADMIN identified by newpassWORD;
Step 3: Encrypt the new modified password in golden gate processes.
ENCRYPT PASSWORD passWORD ENCRYPTKEY DEFAULT
AACAAAAAAAAAAAIAWIVENGVBBFXEFEQH
Step 4: copy the password
dblogin userid GGADMIN, password AACAAAAAAAAAAAIAWIVENGVBBFXEFEQH, encryptkey default
While starting up oracle using following command i get following error:
SQL> startup
ORACLE instance started.
Total System Global Area 288141312 bytes
Fixed Size 2252504 bytes
Variable Size 230687016 bytes
Database Buffers 50331648 bytes
Redo Buffers 4870144 bytes
ORA-00205: error in identifying control file, check alert log for more info
When i check alert logs, i see following message:
Wed Nov 02 05:45:35 2016
ALTER DATABASE MOUNT
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/optware/oracle/11.2.0.4/db_1/dbs/<sid>_control2'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/optware/oracle/11.2.0.4/db_1/dbs/<sid>_control1'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
However when i check list of control files, i see location but dont know why file for control were not created:
SQL> show parameter CONTROL_FILES
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_files string /optware/oracle/11.2.0.4/db_1/
dbs/<sid>_control1, /optwar
e/oracle/11.2.0.4/db_1/dbs/<sid>_control2
DB Creation script:
CREATE DATABASE "mydb"
MAXINSTANCES 8
MAXLOGHISTORY 1
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
DATAFILE '/optware/oradata/mydb/system.dbf' SIZE 1024M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL
SYSAUX DATAFILE '/optware/oradata/mydb/sysaux.dbf' SIZE 1024M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED
SMALLFILE DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE '/optware/oradata/mydb/temp.dbf' SIZE 1500M REUSE AUTOEXTEND ON NEXT 640K MAXSIZE UNLIMITED
SMALLFILE UNDO TABLESPACE "UNDOTB_mydb" DATAFILE '/optware/oradata/mydb/undotbs2.dbf' SIZE 500M REUSE AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED
CHARACTER SET AL32UTF8
NATIONAL CHARACTER SET UTF8
LOGFILE GROUP 1 ('/optware/oradata/mydb/redo1_a1.rdo', '/optware/oradata/mydb/redo1_b1.rdo') SIZE 20M,
GROUP 2 ('/optware/oradata/mydb/redo1_a2.rdo', '/optware/oradata/mydb/redo1_b2.rdo') SIZE 20M,
GROUP 3 ('/optware/oradata/mydb/redo1_a3.rdo', '/optware/oradata/mydb/redo1_b3.rdo') SIZE 20M
USER SYS IDENTIFIED BY "Welcome3" USER SYSTEM IDENTIFIED BY "Welcome3";
Please help
Besides the OP's solution (he had some extra whitespace in the wrong place in the init.ora file), I encountered the exact same errors about controlfiles when I attempted to set a "hidden" parameter_disable_highres_ticks to an apparently invalid value.
I have a table with partitioned by date. Today when I run query for entire month I get following error:
SQL Error [1578] [72000]: ORA-01578: ORACLE data block corrupted (file # 10, block # 19007437)
ORA-01110: data file 10: '\UDR''
unfortunately all this long the database was in no archive log mode as now I know. So further investigating I found out that this block is in partition 9 of the table which holds 9th of Feb data.
So how can I recover from this issue? I try to to validate the blocks from rman and then try to recover it, but I get message that there is no back up for that since my db was in no archivelog mode
any help to either ignore it while running query or if I drop the data of 9th feb and reload them will that fix the issue?
when I do
select * from v$database_block_corruption
file | block# | blocks | corruption_change# | corruption_type |cond_id
10 | 1 | 19007437| 0 | fractured | 0
when I select the block from dba_extents then I see
segment_name | segment_type | block_id
tablename | partitionname | 19007437
How can i take a backup of all database objects(table schema, procedure, function)
and store it in my windows file location every night. I'm connecting using PL/SQL Developer to oracle server located at different location.
To put in short words "I should have backup in my machine rather than the server", Any ideas
Assuming you installed them as part of your Oracle client installation, you could use the Oracle Export and Import utilities to create a logical backup on your client machine.
On the other hand, I would strongly question the wisdom of this requirement. Your DBA ought to be quite concerned about someone generating regular exports of their database that are not under the same controls as the normal backups to prevent them falling into the wrong hands. You're also copying all the data from the database over the network on a regular basis-- that is going to put a substantial load on the database and on the network that are likely to draw the attention of DBAs and network admins.
To back up backup sets from disk to tape:
If you are backing up a subset of available backup sets, then execute the LIST BACKUPSET command to obtain their primary keys.
The following example lists the backup sets in summary form:
RMAN> LIST BACKUPSET SUMMARY;
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Comp Tag
--- -- -- - ----------- --------------- ------- ------- ---- ---
1 B F A DISK 28-MAY-07 1 1 NO TAG20070528T132432
2 B F A DISK 29-MAY-07 1 1 NO TAG20070529T132433
3 B F A DISK 30-MAY-07 1 1 NO TAG20070530T132434
The following example lists details about backup set 3:
RMAN> LIST BACKUPSET 3;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
3 Full 8.33M DISK 00:00:01 30-MAY-07
BP Key: 3 Status: AVAILABLE Compressed: NO Tag: TAG20070530T132434
Piece Name: /disk1/oracle/dbs/c-35764265-20070530-02
Control File Included: Ckp SCN: 397221 Ckp time: 30-MAY-07
SPFILE Included: Modification time: 30-MAY-07
SPFILE db_unique_name: PROD
I am on Windows XP running Oracle 10G XE Edition.
After running a defrag & cleanup process, I have not been able to access any of the objects on the database.
A quick check
set lines110
col strtd hea 'STARTED'
col instance_name for a8 hea 'INSTANCE'
col host_name for a15 hea 'HOSTNAME'
col version for a10
select instance_name, version, host_name, status
, database_status, to_char(startup_time,'DD-MON-YYYY HH:MI:SS') strtd
from v$instance;
returns this
INSTANCE VERSION HOSTNAME STATUS DATABASE_STATUS STARTED
-------- ---------- --------------- ------------ ----------------- ----------------------------------------------------
xe 10.2.0.1.0 DT8775C MOUNTED ACTIVE 03-DEC-2010 11:38:00
If I use this command, it throws the following error.
SQL> ALTER DATABASE OPEN;
ALTER DATABASE OPEN
*
*ERROR at line 1:*
ORA-16014: log 2 sequence# 679 not archived, no available destinations
ORA-00312: online log 2 thread 1:
'D:\ORACLEEXE\APP\ORACLE\FLASH_RECOVERY_AREA\XE\ONLINELOG\O1_MF_2_4JD5RZC0_.LOG'
How can I fix this situation?
There are zero files in the
"D:\ORACLEEXE\APP\ORACLE\FLASH_RECOVERY_AREA\XE\ONLINELOG\" folder.
I'm pretty sure this belongs on SERVERFAULT, but to get you going for now:
It appears the database is in ARCHIVELOG mode and you have not supplied a location to store the archived log files. A quick fix, assuming you don't need the recovery protection that archive logging gives you is to try this:
sqlplus / as sysdba
SQL> shutdown immediate;
SQL> startup mount;
SQL> ALTER DATABASE NOARCHIVELOG;
SQL> ALTER DATABASE OPEN;
If you do want to keep your archived redo logs, then you'll need entries like this in your database parameters:
alter system set log_archive_dest_1='location=d:\oraclexe\app\oracle\...';
alter system set log_archive_dest_state_1=enable;
Sounds like in your cleanup process you may have deleted the .LOG files. I assume you've emptied the trash and can't restore them?