Oracle数据恢复、数据库恢复、灾难恢复

Oracle ORA-1034,ORA-07318: WHEN TRYING TO CONNECT

2013/03/25 by admin Leave a Comment

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

问题描述

===================

当使用远程连接连接到Oracle时尝试在服务器上进行SQL*Net V2 loopback ，或启动 SQL*Net V2 Listener，你收到以下错误：

ORA-01034: “ORACLE not available”

Cause: Oracle was not started up. Possible causes include the following:

– The SGA requires more space than was allocated for it.

– The operating-system variable pointing to the instance is

improperly defined.

Action: Refer to accompanying messages for possible causes and correct

the problem mentioned in the other messages.

If Oracle has been initialized, then on some operating systems,

verify that Oracle was linked correctly. See the platform

specific Oracle documentation.

ORA-07318: “smsget: open error when opening sgadef.dbf file.”

Cause: Unable to open sgadef.dbf file.

Action: Check errno. Possible permission problem. Verify that

sgadef.dbf file exists.

问题说明：

====================

当由于SQL*Net配置文件中的错误，尝试连接到服务器失败时，发生这些错误。由于ORA-7318失败，显示ORA-1034信息。

They can also occur when symbolic links are used to reference $ORACLE_HOME

in some but not all occurences. For example, if symbolic links are used in

the database file names in the control files but not in the “listener.ora”.

在一些但不是所有情况中，当符号链接用来引用$ ORACLE_HOME，它们也会发生。例如，如果符号链接用于在控制文件中的数据库文件名而不是在“listener.ora中”。

搜索词

============

ora-01034 ora-07318 sqlnet, sqlplus, SQL*Plus, upgrade, upgrading

在listener.ora，init.ora 和tnsnames.ora中查看SID的大小写

解决方案描述：

———————

Unix 是大小写敏感的。

在listener.ora，init.ora 和tnsnames.ora中查看SID的大小写。

lsnrctl status 来查看它正在监听哪个sid 大写/小写。

解决方案说明：

———————

确保listener.ora ，tnsnames.ora 和init.ora 中的所有sid大小写相同。

解决方案参考：

——————–

Note:95526.1

Note:69546.1

Note:1056155.6

UNIX: MAKE SURE SID MATCHES ENTRIES IN “TNSNAMES.ORA”

解决方案描述：

=====================

这可能由Listener 和/或tnsnames 和”sgadef<SID>”条目键的SID名称错配导致。

查找你的”sgadef<SID>.dbf” 文件。在UNIX上，它位于目录”$ORACLE_HOME/dbs”中。确保<SID> 匹配在你的”tnsnames.ora”文件和”listener.ora” file文件中的条目。在UNIX中，它是大小写敏感的，所以大小写要匹配。如果你做过更改，进行必要的纠正并重启。

解决方案说明：

=====================

在实例启动时，数据文件”sgadef<SID>.dbf”被创建且它的函数要储存SGA的内存位置的地址。

Server Manager 起作用，因为它在使用本地连接，SQL*Plus失败显示这些错误，因为它在尝试使用SQL*Net 且无法绕过SID错配。

VERIFY THAT PARENTHESIS MATCH IN “LISTENER.ORA”

解决方案描述：

=====================

查看”listener.ora” 文件并验证所有所有的括号匹配，尤其在the SID_LIST_<LISTENER> = portion of the file specific to the instance that is failing。

特定SID_LIST_<LISTENER> = entry 将如下所示：

…

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = ORCL.world)

(SID_NAME = ORCL)

)

解决方案说明：

=====================

Listener在它的配置文件中未识别出SID，且无法找出创建连接所需的所有数据库文件。

VERIFY ALIASES MATCH BETWEEN CLIENT AND SERVER

解决方案描述：

=====================

确保在客户端 (PC)的”tnsnames.ora” 文件中的条目完全匹配在服务器段的”tnsnames.ora”文件中的条目，尤其是引用的大小写。PC端更容忍大/小写不一致性，但UNIX不是。如果条目不同，SQL*Net 会无法创建连接。

例如：

在服务器段的 “tnsnames.ora” 文件中，数据库的条目是：

production = (DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = sam) (PORT = 1521))

)

(CONNECT_DATA = (SID = PROD)))

在客户端的 “tnsnames.ora” 文件中，数据库的条目是：

PRODUCTION = (DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = sam) (PORT = 1521))

)

(CONNECT_DATA = (SID = PROD)))

解决方案说明：

=====================

文件中的区别会导致客户端的SQL*Net 连接失败。将客户设为小写能解决连接失败。为建立PC和UNIX服务器键的连接，别名（alias）必须完全匹配。

VERIFY “ORACLE_SID” AND “ORACLE_HOME” SET CORRECTLY

解决方案描述：

=====================

确保设置了环境变量”ORACLE_SID” 和 “ORACLE_HOME”，且它们的大小写适当。在UNIX上：

% echo $ORACLE_SID

% echo $ORACLE_HOME

同时通过检查后台检查pmon来检查数据库是否在运行：

% ps -ef |grep ora_pmon_$ORACLE_SID

解决方案说明：

=====================

如果”ORACLE_SID” 未正确设置，则pmon 不会存在。这也可能是因为数据库不在运行。

如果未正确设置”ORACLE_HOME” ，Oracle将不知道其文件架构是否保留且无法导向该架构中相关的文件路径。这样设置提供不同目录布局的适应能力。

MAY NEED TO REMOVE “$ORACLE_HOME/DBS/SGADEF<SID>.DBF”

解决方案描述：

=====================

If these errors are received when starting up a SQL*Net V2 Listener, check to

see if your database is running. If the database is not running, then you may

need to remove the “$ORACLE_HOME/dbs/sgadef<SID>.dbf” file. If the database is

running, it may need to be restarted. This is not a networking issue but a

database problem that will prevent the listener from starting.

如果在启动SQL*Net V2 Listener时收到这些错误，查看你的数据库是否在运行。如果数据库没有运行，那么你可能需要删除“$ ORACLE_HOME / dbs / sgadef<SID>.dbf”文件。如果该数据库在运行，它可能需要被重启。这不是网络的问题，而是数据库的问题，这会使监听器的无法启动。

解决方案说明：

=====================

SGA (Shared Global Area)是一个内存cache，每次在Oracle数据库启动时被创建，在相应数据库关闭时被删除。如果数据库未正常关闭（例如由于硬件故障的系统重启），则文件 “$ORACLE_HOME/dbs/sgadef<SID>.dbf” 无法被正确删除且可能导致这些错误。如果在Listener启动时数据库不在运行，删除 “$ORACLE_HOME/dbs/sgadef<SID>.dbf”文件。如果此时数据库在运行，作为正确的oracle/dba用户停止并重启数据库。

CHECK SETTING OF $ORACLE_HOME IN “LISTENER.ORA” FILE OF SID

解决方案描述：

=====================

确保在你尝试连接的SID上，正确的 $ORACLE_HOME 在”listener.ora” 文件中被定义。

解决方案说明：

=====================

如果你的$ORACLE_HOME变量未被正确定义，储存SGA的内存位置地址的数据文件”sgadef<SID>.dbf”会无法找到。

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle 在NOARCHIVELOG 模式尝试打开数据库时，ORA-376, ORA-01110

2013/03/25 by admin Leave a Comment

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

oerr ora 1589
01589, 00000, "must use RESETLOGS or NORESETLOGS option for database open"
// *Cause: Either incomplete or backup control file recovery has been
// performed. After these types of recovery you must specify either
// the RESETLOGS option or the NORESETLOGS option to open your
// database.
// *Action: Specify the appropriate option.

问题描述

——————-

在mount阶段尝试启动数据库导致以下：

ORA-00604: Error occurred at recursive SQL level 1

ORA-00376: File 2 cannot be read at this time

ORA-01110: data file 2: ‘d:\oracle\oradata\oracle\RBS01.dbf’

数据库在NOARCHIVELOG模式下运行，无损坏，无冷备份。

解决方案说明

——————–

一种选择是假装恢复，看看Oracle恢复数据库需要什么文件。如果Oracle只需要联机重做日志，则数据库可以被恢复并打开，而没有数据丢失。

在SQL*PLUS或 SVRMGL：

运行以下查询来确认联机重做日志的序列号：

SQL>select v1.group#,member,sequence#,first_change#

from v$log v1, v$logfile v2

where v1.group# = v2.group#;

记下序列号和成员列很重要。

接下来，尝试恢复数据库来查看Oracle 需要什么文件：

SQL>recover database until cancel;

再次记下序列号。忽略建议的日志文件名称。名称会以归档日志的形式出现，但这确实是尚未归档的联机重做日志的名称。

如果查询结果中最低的序列号与Oracle需要恢复数据库的序列号相同，则数据库能被恢复。

只要从成员列复制确切的路径和文件名作为 RECOVER DATABASE 命令所需的文件名。

对每个联机重做日志重复过程。

Oracle会返回提示，恢复完成。

此时你能发出：

SQL> Alter database open

如果ORA-1589 “must use RESETLOGS or NORESETLOGS option for database open” 发生：

SQL> > Alter database open NORESETLOGS

注:打开可能要一段时间。

参考

———-

其他搜索词

———————–

ORA-1110 recovery online redo logs noarchive

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle 在备份和恢复中发现的ORA-376 错误的常见原因和解决方案

2013/03/24 by admin Leave a Comment

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

oerr ora 376
"file %s cannot be read at this time"
// *Cause: attempting to read from a file that is not readable. Most likely
// the file is offline.
// *Action: Check the state of the file. Bring it online

适用于：

Oracle Database – Enterprise Edition – 版本 9.0.1.0 到 11.2.0.3 [Release 9.0.1 to 11.2]
本文信息适用于任何平台。

目的

夯实ORA-376错误的常见原因和解决方案。

故障排除步骤

SCOPE & APPLICATION
——————-

Customers facing ORA-376 or analysts requiring information on known issues
with ORA-376 errors.
ORA-376
=======

An ORA-376 occurs when Oracle knows a datafile, but Oracle cannot read it.
错误说明：
—————–

Error: ORA 376 file %s cannot be read at this time

Cause: attempting to read from a file that is not readable. Most likely the file is offline.

Action: Check the state of the file. Bring it online
如错误本文所述，该错误的常见原因是由于Oracle无法读取特定数据文件。该错误通常会伴随ORA-1110，这会给出Oracle无法读的文件名。

例如：

ORA-00376: file 28 cannot be read at this time
ORA-01110: data file 28: ‘/h04/usupport/app/oracle/oradata/v817/test.dbf’

在这里，test.dbf 是Oracle无法读取的数据文件名。
可能原因及解决方案：
=====================================

表空间或数据文件脱机。
B. 在OS级别数据文件不存在。
C. 被Backup Software锁住的数据文件。
D. 在UNIX上错误设置ULIMIT。
E. 含活跃事务的回滚段不可用。
F. 其他可能原因。
表空间或一个表空间中的数据文件脱机。

– 使用以下查询来找出表空间的状态：

SQL> select tablespace_name,status from dba_tablespaces;

– 使用以下查询找出数据文件的状态。

SQL> select file#,name,status,enabled from v$datafile;

– 如果表空间脱机，你能通过以下使它联机：

SQL> alter tablespace <tablespace_name> online;

– 如果一个表空间中的数据文件脱机，你能通过以下使它联机：

SQL> alter database datafile <full_path_datafile_name> online;

在一些情况下，数据文件的状态可能是’recover’。在这种情况下，必须进行媒体恢复使数据文件联机。否则，会遇到Else, ORA-1113：

例如：

ORA-01113: file 28 needs media recovery
ORA-01110: data file 28: ‘/h04/app/oracle/oradata/v817/nar.dbf’

恢复可以使用以下命令：

SQL> recover datafile ‘<full_path_of_datafile>’;

SQL> alter database datafile <full_path_datafile_name> online;

在一些情况下，仅从重做日志恢复数据文件是可能的。

在OS级别数据文件不存在。

在这种情况下，你能drop数据文件并重建表空间。但这仅对于非系统（包括SYSAUX）和非回滚表空间。

简要步骤为：

– 作为SYSDBA登录到Oracle。

– 脱机drop 与表空间相关的其他数据文件

SQL> ALTER DATABASE DATAFILE ‘<datafile_name>’ OFFLINE DROP;

– Drop表空间

SQL> DROP TABLESPACE <tablespace_name> INCLUDING CONTENTS;

– 重建表空间

SQL> CREATE TABLESPACE <tablespace_name> DATAFILE ‘<datafile_name>’
SIZE <required_size>;

由于Backup软件锁住文件。

在一些平台中，backup 软件可能会锁住数据文件，阻止Oracle读取数据文件。检查是否有备份软件运行并停止它们，从而释放锁，并尝试重启数据库。

在Unix上，如果未正确设置ulimit。

如果未未正确设置ulimit，可能生成以下错误。尤其是在Oracle Parallel Server (OPS) 实例中，其中可能发生节点切换。

例如：

ORA-00376: file 29 cannot be read at this time
ORA-01110: data file 29: ‘/db/GICORP_4/axix01.dbf’
Error: 27: File too large

问题是在新节点上，文件大小限制小于在旧节点上的限制且小于数据文件大小。

在这些情况下，解决方法是增加 Unix ulimit 文件大小，如下。
对于C shell：
—————-

% limit filesize <number>

对于Bourne 或 Korn shell:
—————————–

$ ulimit -f <number>
一旦ulimit 增加，在使数据文件联机后（如果它们脱机），数据库能被重启。

如果包含活跃事务的回滚段不可用。

在以下情况下也可能出现ORA-376错误：

由于数据库关闭中止或系统崩溃而故障。
2. 在回滚段表空间的一个数据文件丢失，由于磁盘损坏，控制器问题等。
3. 在删除rollback_segments 参数中的条目后，数据库后续被启动。
4. 回滚数据文件被脱机drop。
5. Database open 命令被发出。

在这个情况下，ORA-376的原因是：

Oracle 自动执行恢复使所有数据库文件回到一致状态。为此，它需要重做日志和回滚段的信息。

如果在过程中需要一个包含回滚段extent的数据文件，但发现是脱机的，Oracle会发出错误。
这个情况的解决方案是：

如果回滚数据文件能再次可用，则

重新将回滚段包括在”init.ora”文件中。2. Mount 数据库。

SQL> STARTUP MOUNT;

使数据文件重新联机。

SQL> ALTER DATABASE DATAFILE ‘<full_path_file_name>’ ONLINE;

在数据文件执行媒体恢复。

SQL> RECOVER DATAFILE ‘<full_path_file_name>’;

打开数据库。

SQL> ALTER DATABASE OPEN;
如果步骤4 失败且文件无法被恢复或回滚数据文件物理丢失，则参考Note:1013221.6。

在这个情况下，解决方案取决于数据库最后是否被干净关闭。

其他错误ORA-376 被解决的情况有：

1.回滚段数据文件被显示，但在启动数据库时，Oracle报错ORA-376。

数据库在NOARCHIVE log 模式且无冷备份。

解决方案：

一个选择是假装恢复来查看Oracle需要什么文件来恢复数据库。如果Oracle只需联机重做日志，则数据库能被恢复并启动，而无数据丢失。

在SQL*Plus 或SVRMGL：

运行以下查询，以确定联机重做日志的序列号：

SQL> select v1.group#,member,sequence#,first_change#
from v$log v1, v$logfile v2
where v1.group# = v2.group#;

记下序列号和成员列很重要。

然后，尝试恢复数据库以查看Oracle需要什么文件：

SQL> recover database until cancel;

再记下序列号。忽略建议的日志文件名。该名称会以归档日志的形式出现，但它确实是尚未归档的联机重做日志的名称。

如果查询结果中最低的序列号与Oracle需要恢复数据库的序列号相同，则数据库能被恢复。

只要从成员列复制确切的路径和文件名作为 RECOVER DATABASE 命令所需的文件名。

对每个联机重做日志重复过程。

Oracle会在恢复的结尾返回信息”Recovery completed.” 。

此时你能发出：

SQL> ALTER DATABASE OPEN;

如果ORA-1589 “must use RESETLOGS or NORESETLOGS option for database open” 发生：

SQL> ALTER DATABASE OPEN NORESETLOGS;

注:打开可能要一段时间。

关闭中止随后服务器重启。
——————————————-

数据库启动失败，显示以下错误：

ORA-01545: rollback segment ‘%s’ specified not available
ORA-01595: error freeing extent (%s) of rollback segment (%s))
ORA-00376: file %s cannot be read at this time

在服务器被重启之前，archive log模式下的数据库被关闭中止。

这个问题的原因仍未确定，但以下解决方案可用：

– 立即关闭数据库：

SQL>shutdown immediate;

– 编辑 init<SID>.ora 文件并在ROLLBACK_SEGMENTS参数中回滚段的列表中删除或注释问题回滚段。

– 启动数据库。

SQL> STARTUP MOUNT;

– 通过运行以下语句，找出哪些文件要恢复：

SQL> select * from v$recover_file;

或者，你也能查询v$datafile。

– 通过以下以下语句，找出哪个回滚段要恢复；

SQL> select usn,status from v$rollstat where status != ‘ONLINE’;

– 恢复需要恢复的数据文件：

SQL> recover datafile ‘<full path filename>’;

– 通过运行以下语句，找出哪个数据文件脱机：

SQL> select name,status
from v$datafile
where status != ‘ONLINE’;

– 使数据文件联机：

SQL> alter database datafile ‘<full path filename>’ online;

– 验证所有数据文件都联机：

SQL> select file#, name, status from v$datafile;

– 通过运行以下语句，找出哪个回滚段脱机：

SQL> select usn,status from v$rollstat where status != ‘ONLINE’;

– 使所有回滚段联机：

SQL> alter rollback segment <RBS NAME> online;
– 验证所有回滚段现在联机：

SQL> select usn,status from v$rollstat ;

– 立即关闭数据库：

SQL> shutdown immediate;

– 编辑init<SID>ora 文件并添加或取消注释问题回滚段到ROLLBACK_SEGMENTS 参数中的回滚段列表。

– 启动数据库。

SQL> STARTUP MOUNT;

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle 数据库崩溃显示ORA-1092 错误

2013/03/22 by admin Leave a Comment

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

oerr ora 01092
01092, 00000, "ORACLE instance terminated. Disconnection forced"
// *Cause:  The instance this process was connected to was terminated
//          abnormally, probably via a shutdown abort. This process
//          was forced to disconnect from the instance.
// *Action: Examine the alert log for more details. When the instance has been 
//          restarted, retry action.

适用于:

Oracle Database – Enterprise Edition – Version 9.2.0.8 及以上
本文信息适用于任何平台。

症状

数据库崩溃，在警告日志中显示以下错误：

Wed Nov 02 06:23:51 2011
Non critical error ORA-00001 caught while writing to trace file “/opt/diag/rdbms/prd1/PRD1/trace/PRD1_arc1_2076702.trc”
Error message: IBM AIX RISC System/6000 Error: 5: I/O error
Additional information: 1
Writing to the above trace file iWed Nov 02 06:29:56 2011
USER (ospid: 643220): terminating the instance due to error 1092
Wed Nov 02 06:29:56 2011
ORA-1092 : opitsk aborting process
Instance terminated by USER, pid = 643220

在崩溃之前查看警告日志中的条目，显示如下：

a. DBWR 进程遇到I/O 错误：

Wed Nov 02 06:23:38 2011
Non critical error ORA-00001 caught while writing to trace file “/opt/diag/rdbms/prd1/PRD1/trace/PRD1_dbw0_2875438.trc”
Error message: IBM AIX RISC System/6000 Error: 5: I/O error
Additional information: 1
Writing to the above trace file is disabled for now on…

警告日志中的条目不完整：

Writing to the above trace file iWed Nov 02 06:29:56 2011 —–> as you see here the output is truncated.

MMON 进程跟踪文件显示：

Unix process pid: 1949800, image: oracle@prdserver (MMON)
*** 2011-11-02 06:23:43.879
Taking over instance termination because the instance terminator (ospid: 2875438) is dead
===> 2875438 is the OS PID of DBW0 process which encountered the I/O error and is dead.

实例通过OS PID 643220的USER进程终止。

该进程的跟踪文件显示：

Taking over instance termination because the instance terminator (ospid: 2191470) is dead
kjzduptcctx: Notifying DIAG for crash event
—– Abridged Call Stack Trace —–
ksedsts()+644<-kjzdssdmp()+444<-kjzduptcctx()+272<-kjzdicrshnfy()+96<-ksuitm()+1284<-ksuitr()+92<-ksu_dispatch_tac()+372<-kdifxs1()+468<-kdifxs()+28<-qerixtFetch()+940
<-qerilFetch()+276<-opifch2()+7136<-opifch()+60<-opiodr()+3608<-rpidrus()+536<-skgmstack()+208
<-rpidru()+144<-rpiswu2()+1124<-rpidrv()+2892<-rpifch()+80
—– End of Abridged Call Stack Trace —–

*** 2011-11-02 06:29:56.242
USER (ospid: 643220): terminating the instance due to error 1092

OS 日志 (/var/log on AIX) 报告 I/O 错误：

Date/Time: Wed Nov 2 06:29:52 CUT 2011

Description
USER DATA I/O ERROR

Probable Causes
ADAPTER HARDWARE OR MICROCODE
DISK DRIVE HARDWARE OR MICROCODE
SOFTWARE DEVICE DRIVER
STORAGE CABLE LOOSE, DEFECTIVE, OR UNTERMINATED

原因

可能是数据文件脱机/损坏：

查看OFFLINE文件：

select file#, status, name from v$datafile where status not in (‘SYSTEM’, ‘ONLINE’);

或
$ORACLE_HOME中的密码文件(orapw)/在数据库创建后创建的dbs中有问题。re is a problem in the password file found in $ORACLE_HOME/dbs which was created after the database creation. 从而导致同步问题且最终造成额外的错误信息：
ORA-01990: error opening password file $ORACLE_HOME/dbs/orapw.

或

DBW0 由于I/O 错误崩溃。这因此导致实例被终止，因为后台进程的终止会造成实例崩溃。

解决方案

数据文件损坏/脱机:
检查你是否有能从中还原任意问题数据文件的好备份。
1) 首先还原有问题的数据文件
2) Mount数据库并使这些数据文件联机

SQL> startup mount;
SQL> alter database datafile file1#, .. , filen# online;

3) 恢复数据库

SQL> recover database;

4) 打开数据库

SQL > alter database open ;

I/O 错误

联系你的系统/Unix 管理员并纠正导致I / O错误的硬件问题。

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle 尝试启动数据库时ORA-16014 ORA-00312

2013/03/22 by admin Leave a Comment

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com



[oracle@ocm_rac01 ~]$ oerr ora 16014
16014, 00000, "log %s sequence# %s not archived, no available destinations"
// *Cause:  An attempt was made to archive the named log, but the archive was 
//          unsuccessful. The archival failed because there were no archive log
//          destinations specified, or all destinations are in an error state.
// *Action: Verify that archive log destinations are specified or
//          take the necessary step to correct any errors that may have
//          occurred.
[oracle@ocm_rac01 ~]$ oerr ora 00312
00312, 00000, "online log %s thread %s: '%s'"
// *Cause:  This message reports the filename for details of another message.
// *Action: Other messages will accompany this message. See the
//          associated messages for the appropriate action to take.

适用于:

Oracle Database – Enterprise Edition – Version 11.1.0.6 及以上
本文信息适用于任何平台。

症状

++ DB 当前在mount阶段，同时OPEN 模式启动遇到ORA-03113:

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 20052
Session ID: 661 Serial number: 5

++ When going through alert log we see DB terminating due to archival issue

Errors in file /opt/oracle/app/oracle/diag/rdbms/stbydb3/stbydb3/trace/stbydb3_ora_47516.trc:
ORA-16014: log 1 sequence# 1 not archived, no available destinations
ORA-00312: online log 1 thread 1: ‘/u02/oradata/stbydb3/redo01.log’
Wed Mar 02 17:28:23 2016
ARC1 started with pid=21, OS id=47526
USER (ospid: 47516): terminating the instance due to error 16014
System state dump requested by (instance=1, osid=47516), summary=[abnormal instance termination].

++ 问题日志是遇到归档时数据库LSTBYDB3本身的一部分

LOG FILE #1:
name #3: /u02/oradata/stbydb3/redo01.log
Thread 1 redo log links: forward: 2 backward: 0
siz: 0x19000 seq: 0x00000001 hws: 0x4 bsz: 512 nab: 0x53 flg: 0x0 dup: 1
Archive links: fwrd: 2 back: 0 Prev scn: 0x0000.00000000
Low scn: 0x0002.4574ba13 03/01/2016 14:29:46
Next scn: 0x0002.4574bb46 03/01/2016 14:29:55
FILE HEADER:
Compatibility Vsn = 186646528=0xb200000
Db ID=3146476263=0xbb8b6ae7, Db Name=’LSTBYDB3′
Activation ID=3146466297=0xbb8b43f9
Control Seq=905350111=0x35f68bdf, File size=102400=0x19000
File Number=1, Blksiz=512, File Type=2 LOG
Format ID is 2
redo log key is 894a8dc04d6d24cf3581f60492a7aef
redo log key flag is 5
descrip:”Thread 0001, Seq# 0000000001, SCN 0x00024574ba13-0x00024574bb46″

原因

本地归档的配置(这里是log_archive_dest_1 )错误地指向不同的db_unique_name “lstbydb3” 而实际上它是stbydb3

log_archive_dest_1=’LOCATION=/u02/archs/stbydb3/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=lstbydb3′

..
db_name = “lstbydb3”
db_unique_name = “stbydb3”

解决方案

连接到SQL*Plus，更正在”log_archive_dest_1″上的”db_unique_name” 参数并尝试打开 DB

alter system set log_archive_dest_1=”LOCATION=/u02/archs/stbydb3/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=stbydb3″;
alter database open;

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle 在警告日志中报告错误ORA-00338, ORA-00312

2013/03/22 by admin Leave a Comment

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

适用于:

Oracle Database – Enterprise Edition – Version 11.2.0.1 及以上
本文信息适用于任何平台。

症状

以下错误在一个RAC节点的警告日志中反复报告。
注意实际问题适用于RAC 和非RAC 数据库。

ORA-00338: log <Log_Number> of thread <thread_number> is more recent than control file
ORA-00312: online log <Log_Number> thread <thread_number>: ‘redo.log’

原因

The ORA-00338 normally indicates an incorrect control file may be used:

00338, 00000, “log %s of thread %s is more recent than control file”
// *Cause: The control file change sequence number in the log file is
//         greater than the number in the control file. This implies that
//         the wrong control file is being used. Note that repeatedly causing
//         this error can make it stop happening without correcting the real
//         problem. Every attempt to open the database will advance the
//         control file change sequence number until it is great enough.
// *Action: Use the current control file or do backup control file recovery to
//         make the control file current. Be sure to follow all restrictions
//         on doing a backup control file recovery.

The error is reported when the log sequence number is greater than the sequence number in the control file.
The process that detects this, posts the entries to the alert log.

Given the normal cause of the error, please verify first that the correct control file is being used.

In this particular case the control file updates could not keep up with the rate of log switches, e.g. 5 to 6 per minute.
The difference in log sequence numbers came from the excessive redo log switches that occurred prior to the error.
Note that also “Log file switch (checkpoint incomplete)” messages were reported.

In this case, the customer mentioned that fast log switches were forced by the ‘storage side backup settings’, meaning their backup implementation/application issued fast ‘alter system switch log file’ commands.

解决方案

在验证正确的控制文件被适用，通过减少快速显式重做日志切换，该问题能被解决。

以防日志切换未被手动或由一个应用（如在这个情况中）强制，可以执行以下检查/行为：

查看重做日志文件大小，确保足以容纳工作负载。
以下文档示例如何调整重做日志文件的大小

Note 1035935.6 – Example of How To Resize the Online Redo Logfiles

在调整重做日志文件大小后，监控你的数据库警告日志来确定日志切换之间的时间。

Oracle 建议每20~30分钟重做日志切换。

注意:
你能使用V$INSTANCE_RECOVERY 视图列OPTIMAL_LOGFILE_SIZE 来确定对你联机重做日志的建议大小。
该字段根据FAST_START_MTTR_TARGET的当前设置，以MB显示最优的重做日志文件的大小。
如果该字段连续显示高于你最小联机日志的大小的值，则你应至少配置所有的联机日志为该大小。

查看哪个会话在生成大量重做。
以下文档显示如何找出哪个会话生成大量重做或归档数据：

Note 167492.1 – SQL: How to Find Sessions Generating Lots of Redo or Archive logs

获得该错误的另一个可能原因是列出的重做日志无效(如包含0)，验证重做日志来确认它是否是有效重做。如果有0，且它是当前的联机日志，则我们需要查看还原/恢复选项。

例如:

SQL> alter system dump logfile ‘/u02/app/oracle/oradata/EBSPROD/redo/log02a.dbf’ validate;
alter system dump logfile ‘/u02/app/oracle/oradata/EBSPROD/redo/log02a.dbf’ validate
*
ERROR at line 1:
ORA-00339: archived log does not contain any redo
ORA-00334: archived log: ‘/u02/app/oracle/oradata/EBSPROD/redo/log02a.dbf’

…
SQL> alter system dump logfile ‘/u02/app/oracle/oradata/EBSPROD/redo/log02b.dbf’ validate;
alter system dump logfile ‘/u02/app/oracle/oradata/EBSPROD/redo/log02b.dbf’ validate
*
ERROR at line 1:
ORA-00339: archived log does not contain any redo
ORA-00334: archived log: ‘/u02/app/oracle/oradata/EBSPROD/redo/log02b.dbf’

In a Data Guard environment that uses ASYNC redo transport, if ORA-338 errors occur in NSA trace file, and the connection with the remote database is closed, and will not reopen until the next log switch, then it could be due to
Bug 12770551 – Frequent ORA-338 during controlfile restore with ASYNC Data Guard (Doc ID 12770551.8)

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

ORA-600 [kgskexitsch] 由于Resource Manager，Oracle 11g 数据库崩溃

2013/03/22 by admin Leave a Comment

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

症状
在从10.2.0.4升级到11.1.0.7.1或11.2.0.1时，我们看到数据库崩溃，显示以下错误：

ORA-00600: 内部错误代码，参数: [kgskexitsch]
stack trace会包含以下：
… <- kgeadse <- kgerinv_internal <- kgerinv <- kgeasnmierr <- kgskexitsch <- kgskflt <- kgskmkinactint <- kskactsesidlechkact <- kskdbrmtoutact <- ksbcti <- ksbabs <- ksbrdp <- opirip <- opidrv <- sou2o <- opimai_real <- opimai <- BackgroundThreadStart

更改
升级到11.2.0.1
原因
这是在11.2.0.2版本中被修复的 Bug 9135679 。
该问题是由包括在11.1.0.7.1 Patch Set Update (PSU) 和11.2.0.1 基础版本中的内部bug 6618461的修复导致的。这导致当启用Resource Manager时的倒退（regression），导致ORA-600 [kgskexitsch]错误和潜在崩溃。
解决方案
1. 如果在11.2上：
a. 应用11.2.0.2 patch set。
b. 如果使用Windows，应用11.2.0.1 patch 4 (或更高)。
• 对于Windows 32位，11.2.0.1 patch 4 是 Patch 9888297
• 对于Windows 64位，11.2.0.1 patch 4是 Patch 9888298
OR
2. 如果在11.1上：
a. 应用 11.1.0.7.2 PSU (Patch 9209238) 或更高。
b. 如果使用Windows，应用11.1.0.7 patch 22 (或更高)。
• 对于Windows 32位，11.1.0.7 patch 22 是 Patch 9166858
• 对于Windows 64位，11.1.0.7 patch 22是Patch 9166861

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle在数据库启动时产生的错误 ORA-48178 和 ORA-27041

2013/03/21 by admin Leave a Comment

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com


[oracle@ocm_rac01 ~]$ oerr ora 48178
48178, 00000, "error encountered while reading an ADR block file during ADR initialization [%s]" 
// *Cause: An error was encountered while reading an ADR block file during
//         the initialization of the ADR subsystem.
// *Action: Check the state of the file system.

[oracle@ocm_rac01 ~]$ oerr ora 27041
27041, 00000, "unable to open file"
// *Cause:  open system call returned an error, additional information
//          indicates which function encountered the error
// *Action: check errno

适用于：
Oracle服务器 – 企业版 – 版本: 11.2.0.1 to 11.2.0.1 – Release: 11.2 to 11.2
本文信息适用于任何平台。
症状
在新创建的11.2.0.1数据库的启动时产生以下错误：
ERROR: ORA-48178 encountered when checking if the process is able to
ERROR: create the ADR schema in the specified ADR Base directory [/d01/oratest/TEST/11.2.0/admin]
ERROR: The ORA-48178 error is caused by the ORA-48122 error.
ORA-48122: error with opening the ADR block file [/d01/oratest/TEST/11.2.0/admin/diag/rdbms/test/TEST/metadata/ADR_INTERNAL.mif] [0]
ORA-27041: unable to open file
Linux-x86_64 Error: 13: Permission denied
Additional information: 2
ERROR: Check if the directory is readable and check if the OS version is supported for ADR.
ERROR: The process will switch back to the pre-ADR method of tracing and logging.

更改
错误在创建新数据库后发生。
原因
该问题的原因在Bug:10086423中被指出。这是由该新数据库的ADR目录结构中的元数据文件（.ASM 和 .MIF文件）上的错误文件权限导致的。
解决方案
该问题在11.2.0.2 patchset和更改版本中解决。
要处理该问题，手动设置权限所涉及的文件，就像在：
$ chmod 760 /d01/oratest/TEST/11.2.0/admin/diag/rdbms/test/TEST/metadata/ADR_INTERNAL.mif

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

处理Oracle RMAN-06023或RMAN-06025

2013/03/21 by admin Leave a Comment

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

[oracle@vrh8 ~]$ oerr rman 6023
6023, 1, "no backup or copy of datafile %d found to restore"
// *Cause:  A datafile, tablespace, or database restore could not proceed
//          because no backup or copy of the indicated file was found.
//          It may be the case that a backup or copy of this file exists but
//          does not satisfy the criteria specified in the user's restore
//          operands.
// *Action: None - this is an informational message.  See message 6026 for
//          further details.
[oracle@vrh8 ~]$ oerr rman 6025
6025, 1, "no backup of log thread %d seq %d lowscn %s found to restore"
// *Cause:  An archive log restore restore could not proceed
//          because no backup of the indicated archived log was found.
//          It may be the case that a backup of this file exists but
//          does not satisfy the criteria specified in the user's restore
//          operands.
// *Action: None - this is an informational message.  See message 6026 for
//          further details.

适用于：
Oracle Database – Enterprise Edition – Version 9.0.1.0 and later
本文信息适用于任何平台。
症状
你收到以下错误：
RMAN-06025: no backup of archived log for thread 1 with sequence 19684 and starting SCN of 1483914453 found to restore
OR
RMAN-06023: no backup or copy of datafile 4 found to restore
原因
当无法识别备份文件是归档日志文件(RMAN-06025)还是数据文件(RMAN-06023)，这些错误由RMAN返回。
解决方案
1. 使用RMAN连接到你运行还原所在的实例(或在运行RMAN复制时的目标)并发出：
RMAN-06025: 无归档日志的备份…….
RMAN> list backup of archivelog sequence <sequence# returned by error>;
例如：
RMAN> list backup of archivelog sequence 19684;
RMAN-06023: 无数据文件的备份……
RMAN> list backup of datafile <number returned by the error>;
例如:
RMAN> list backup of datafile 4;
2. 如果没有返回的备份：
a. 查看你是否应连接到一个目录。
b. 如果没有使用的目录，你需要对包含文件（归档日志或数据文件）的备份创建目录。要这么做，执行：
RMAN> catalog start with ‘/location of backup/’ noprompt;
如果备份在磁带，查看：
Note 550082.1 How to Catalog Tape Backup Pieces
c. 考虑还原一个包含备份信息的控制文件。
3. 如果RMAN返回了备份信息：
a. 查看备份的状态是否可用。
例如：
RMAN> list backup of datafile 4;

List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
——- —- — ———- ———– ———— —————
291 Full 1.06G DISK 00:00:15 27-JUL-15
BP Key: 292 Status: AVAILABLE Compressed: NO Tag: TAG20150727T144532
Piece Name: /u01/oradata/V1124/d8qd3psc_1_1

b. 对于数据文件，查看备份中的数据文件的Ckp SCN/Ckp Time是否在还原/复制所指定的until之前：
例如：
RMAN> list backup of datafile 4;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
——- —- — ———- ———– ———— ——————–
291 Full 1.06G DISK 00:00:15 27-JUL-2015 14:45:47
BP Key: 292 Status: AVAILABLE Compressed: NO Tag: TAG20150727T144532
Piece Name: /u01/oradata/V1124/d8qd3psc_1_1
List of Datafiles in backup set 291

File LV Type Ckp SCN Ckp Time Name
—- — —- ———- ——————– —-
4 Full 59195530 27-JUL-2015 14:45:32 /u01/oradata/V1124/users01.dbf

c. 查看你想要使用的备份是否在CURRENT incarnation中。
例如：
RMAN> list incarnation;
using target database control file instead of recovery catalog
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
——- ——- ——– —————- — ———- ———-
1 1 V1124 82280094 PARENT 1 19-JUN-2015 10:31:58
2 2 V1124 82280094 CURRENT 59448598 29-JUL-2015 12:45:27

在这个情况下，显然27-JUL-2015的备份未在CURRENT incarnation, Reset Time=29-JUL-2015。要还原数据文件4的备份，必须要重置incarnation。
例如：
RMAN> reset database to incarnation 1;
database reset to incarnation 1
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
——- ——- ——– —————- — ———- ———-
1 1 V1124 82280094 CURRENT 1 19-JUN-2015 10:31:58
2 2 V1124 82280094 ORPHAN 59448598 29-JUL-2015 12:45:27

注意: 如果你的归档日志文件获得 ‘specification does not match any archive log..’ ，这就略有不同。该错误表示控制文件不知道现有的archivelog file vs backup。参阅 Note 869671.1 RMAN List / Delete error with “specification does not match any archive log…”

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle 不完整恢复产生ORA-01152

2013/03/21 by admin Leave a Comment

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

[oracle@vrh8 ~]$ oerr ora 1152
01152, 00000, “file %s was not restored from a sufficiently old backup ”
// *Cause: An incomplete recovery session was started, but an insufficient
// number of logs were applied to make the database consistent. This
// file is still in the future of the last log applied. The most
// likely cause of this error is forgetting to restore the file
// from a backup before doing incomplete recovery.
// *Action: Either apply more logs until the database is consistent or
// restore the database file from an older backup and repeat recovery

适用于：
Oracle Database – Enterprise Edition – Version 8.1.7.4 to 11.2.0.4 [Release 8.1.7 to 11.2]
本文信息适用于任何平台。

症状
在不完整恢复后，试图打开数据库获取ORA-1152 。
原因
当文件早于恢复停止点的时间（SCN），发生该错误。
解决方案
要实施该解决方案，执行以下步骤：

1. 找出哪个文件较新：
a. 启动mount 实例
b. 发出以下查询：
sql> select file#, status, checkpoint_change# from v$datafile;
sql> select file#, status, fuzzy, checkpoint_change# from v$datafile_header;

c. 查看checkpoint_change#，找出哪个文件相对其他文件较新。

2. 从之前的备份还原该文件。
3. 重新做不完整恢复

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com