Oracle DBA: February 2008 Archives
长时间以来对Oracle的Release命名法有些模糊,今天查了一下资料记录下来。下面以Oracle Release 9.2.0.1.0为例,说明Oracle的release命名法,如下所示:
Example of an Oracle Release Number
Major Database Release Number
This is the most general identifier. It represents a major new edition (or version) of the software that contains significant new functionality.
Database Maintenance Release Number
This digit represents a maintenance release level. Some new features may also be included.
Application Server Release Number
This digit reflects the release level of the Oracle9i Application Server (Oracle9iAS).
Component Specific Release Number
This digit identifies a release level specific to a component. Different components can have different numbers in this position depending upon, for example, component patch sets or interim releases.
Platform Specific Release Number
This digit identifies a platform specific release. Usually this is a patch set. Where different platforms require the equivalent patch set, this digit will be the same across the effected platforms.
Note: Starting with release 9.2, maintenance releases of Oracle are denoted by a change to the second digit of a release number. In previous releases, the third digit indicated a particular maintenance release.
下面几个有用视图可用来检查你的数据库当前版本:
V$OPTION
This view lists options that are installed with the Oracle server.
V$option是指dbms安装的组件。
SQL> select * from v$option;
PARAMETER VALUE
---------------------------------------- --------------------
Partitioning TRUE
Objects TRUE
Real Application Clusters FALSE
Advanced replication TRUE
Bit-mapped indexes TRUE
Connection multiplexing TRUE
Connection pooling TRUE
Database queuing TRUE
Incremental backup and recovery TRUE
Instead-of triggers TRUE
Parallel backup and recovery TRUE
Parallel execution TRUE
Parallel load TRUE
Point-in-time tablespace recovery TRUE
Fine-grained access control TRUE
Proxy authentication/authorization TRUE
Change Data Capture TRUE
Plan Stability TRUE
Online Index Build TRUE
Coalesce Index TRUE
Managed Standby TRUE
Materialized view rewrite TRUE
Materialized view warehouse refresh TRUE
Database resource manager TRUE
Spatial TRUE
Visual Information Retrieval TRUE
Export transportable tablespaces TRUE
Transparent Application Failover TRUE
Fast-Start Fault Recovery TRUE
Sample Scan TRUE
Duplexed backups TRUE
Java TRUE
OLAP Window Functions TRUE
Block Media Recovery TRUE
Fine-grained Auditing TRUE
Application Role TRUE
Oracle Data Guard TRUE
Oracle Label Security FALSE
OLAP FALSE
Heap segment compression TRUE
Join index TRUE
Trial Recovery TRUE
Oracle Data Mining FALSE
Online Redefinition TRUE
Streams TRUE
File Mapping TRUE
47 rows selected.
PRODUCT_COMPONENT_VERSION
PRODUCT_COMPONENT_VERSION contains version and status information for component products.
Product_component_version指rdbms的产品:
SQL> select * from product_component_version;
PRODUCT VERSION STATUS
---------------------------------------- -------------------- --------------------
NLSRTL
Oracle9i Enterprise Edition
PL/SQL
TNS for Solaris:
DBA_REGISTRY
DBA_REGISTRY displays information about the components loaded into the database.
DBA_REGISTRY指数据库中组件的信息:
比如,建库时如选择 Oracle Text,则此视图查询时也会有 Oracle Text这一项。
SQL> select comp_name,version,status from dba_registry;
COMP_NAME VERSION STATUS
------------------------------ -------------------- --------------------
Oracle9i Catalog Views
Oracle9i Packages and Types
Oracle Workspace Manager
发现最近在Oracle 10.2.0.3的RAC环境中,时不时会提示下面错误:
ORA-1461 encountered when generating server alert SMG-3500
经研究发现,其是Oracle 10g的一个Bug,并且目前只有Oracle 10.2.0.3会遇到:
造成这个错误的原因是由于SMON 进程正在 UPDATE SMON_SCN_TIME表时引发了ORA-1461:
下面是诊断信息:
DIAGNOSTIC ANALYSIS:
--------------------
Set the event 1461 and got the smon trace file which shows the error
.
SQL> alter system set EVENT="1461 TRACE NAME ERRORSTACK LEVEL 10"
scope=spfile;
.
ksedmp: internal or fatal error
ORA-01461: can bind a LONG value only for insert into a LONG column
Current SQL statement for this session:
update smon_scn_time set orig_thread=0, time_mp=:1, time_dp=:2, scn=:3,
scn_wrp=:4, scn_bas=:5, num_mappings=:6, tim_scn_map=:7 where thread=0 and
scn = (select min(scn) from smon_scn_time where thread=0)
----- Call Stack Trace -----
ksedmp ksddoa ksdpcg ksdpec ksfpec kgesev
ksesec0 opiobv opipbr opibvg opiexe opiall0
opikpr opiodr rpidrus skgmstack rpidru rpiswu2
kprball ktf_scn_time ktmmon ksbrdp opirip opidrv
sou2o opimai_real main start
ORA-1461错误有时也会和
ORA-01461: can bind a LONG value only for insert into a LONG column 错误一起出现。
Solution:
Oracle提供 Patch 6602742 补丁下载可以解决问题。
不过还好此错误对系统影响不大。
--The End--
大家知道,ORA-03113错误是Oracle数据库常见的错误,导致这个错误的原因比较复杂,各种各样的原因。可能是网络中断引起的、也可能是数据库本身出现了问题。
下面就一个案例,分析一下ORA-03113错误。
故障现象:
开始alert文件提示错误:
Error 1013 trapped in 2PC on transaction 1.60.1257421. Cleaning up.
Error stack returned to user:
ORA-02050: transaction 1.60.1257421 rolled back, some remote DBs may be in-doubt
ORA-01013: user requested cancel of current operation
ORA-06553: PLS-103: Encountered the symbol "EXCEPTION" when expecting one of the following:
begin case declare exit for function goto if loop mod null
package pragma procedure raise return select separate type
update while with <an identifier>
<a double-quoted delimited-identifier> <a bind variable> <<
form table call close current define delete fetch lock
Mon Feb 18 09:07:19 2008
DISTRIB TRAN SMSBOSS.09aad
is local tran 1.60.1257421 (hex=
insert pending collecting tran, scn=8914343855672 (hex=81b
然后时不时的会提示下面错误:
ERROR, tran=1.60.1257421, session#=1, ose=0:
ORA-03113: end-of-file on communication channel
*** 2008-02-18 09:45:25.919
ERROR, tran=1.60.1257421, session#=1, ose=0:
ORA-03113: end-of-file on communication channel
*** 2008-02-18 10:19:42.891
Oracle数据库只有这些错误提示,其余状态均正常。
从错误提示看,应该是由于分布事务由于人为cancel中止,引起的事务失败,下面查看相关信息:
SQL> select LOCAL_TRAN_ID,GLOBAL_TRAN_ID,STATE,MIXED,HOST,COMMIT# from dba_2pc_pending;
LOCAL_TRAN_ID GLOBAL_TRAN_ID STATE MIX HOST COMMIT#
---------------------- -------------------- ---------------- --- -------------------- ----------------
1.60.1257421 SMSBOSS.09aad
SQL> select * from DBA_2PC_NEIGHBORS;
LOCAL_TRAN_ID IN_ DATABASE DBUSER_OWNER I DBID SESS# BRANCH
---------------------- --- --------------- ------------------------------ ----------------- ---------- --------------------
1.
1.60.1257421 out SMSDBN BOSSMGR N cc3ddb9b 1 4
select * from DBA_2PC_PENDING@smsdbn;
no rows selected
select * from DBA_2PC_NEIGHBORS@smsdbn;
no rows selected
dba_2pc_pending视图记录等待恢复的分布式事务的信息
dba_2pc_neighbors视图记录未决的分布式事务的输入输出连接信息
有上述信息分析原因,1.60.1257421事务的状态为collecting,本机数据库数据流向为in,远端smsdbn数据库流向为out。
询问业务人员,确实运行过这么个一存储,中途手工中止了。并且是从smsdbn数据库里select数据然后update本地数据库。 这基本证实了我们的猜测。
下面尝试force commit或者 force rollback此事务,
SQL> commit force '1.60.1257421';
commit force '1.60.1257421'
*
ERROR at line 1:
ORA-02058: no prepared transaction found with ID 1.60.1257421
上述错误的原因是由于collecting状态的事务不需要commit/rollback force。
我们现在需要做的就是:
(1) Disable分布式恢复
SQL> ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY;
System altered.
(2)Puege(清空)in-doubt transaction entry:
SQL> exec DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('1.60.1257421');
PL/SQL procedure successfully completed.
(3)然后enable 分布式恢复:
SQL> ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY;
参考信息/更多阅读:
Note:1012842.102
ORA-2019 ORA-2058 ORA-2068 ORA-2050: Failed Distributed Transactions
Note:100664.1
How to Troubleshoot Distributed Transactions
Note:274321.1
Note:126069.1
Manually Resolving In-Doubt Transactions: Different Scenarios
--The End--
故障现象:
Oracle 9208 DataGuard日志应用正常,但是在standby alter log文件里老是提示下面错误:
|
RFS: Possible network disconnect with primary database |
Metalink的解释:
|
Symptoms Standby alert log reports "RFS: Possible network disconnect with primary database" At the standby DB side I get this error every minute. Archive log transfer/apply works O.K. Cause The (error) message may be triggered by another database that has log_archive_dest_2 pointing to standby instance of (error) message . RFS process tries to communicate with the instance. Solution Check if you have DB with mismatched ID and its log_archive_dest_X parameter value. From the error message of "Standby database ID mismatch [0xAAAA:0xBBBBB]" Convert the hex number of first argument, 0xAAAA to decimal value using calculator Then search db with the dbid. |
按照上述说明,果然在primary database所在主机上,找到了另外一个实例,其参数log_archive_dest_2的设置也是:
log_archive_dest_2 string SERVICE=standby
将log_archive_dest_2参数defer后,即可解决问题。
关于log_archive_dest_n参数的设置说明:
(
说明: 指定相应的归档日志目标参数 (仅 LOG_ARCHIVE_DEST_3) 的可用性状态。如果启用,
日志目标将被归档。如果延迟, 该目标将被排除在归档操作之外直至重新启用。
值范围: ENABLE | DEFER
)
Logfile的不同状态
一、 V$LOG:STATUS 指的是GROUP的状态
UNUSED:
尚未记录change的空白group(一般会出现在,loggroup刚刚被添加,或者刚刚使用了resetlogs打开数据库,或者使用clear logfile后)
CURRENT:
当前正在被LGWR使用的group(同时是ACTIVE状态)
ACTIVE:
未被LGWR写,instance recovery需要的。还没有完成checkpoint。
INACTIVE:
online,未被LGWR写,对instance recovery不再有用了。