Oracle DBA: February 2008 Archives

Oracle Release Number Format含义

| | Comments (0)

长时间以来对Oracle的Release命名法有些模糊,今天查了一下资料记录下来。下面以Oracle Release 9.2.0.1.0为例,说明Oracle的release命名法,如下所示:

Example of an Oracle Release Number

 

 

 

oracle release number format.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

Enterprise User Security                 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_versionrdbms的产品:

 

SQL> select * from product_component_version;

PRODUCT                                  VERSION              STATUS

---------------------------------------- -------------------- --------------------

NLSRTL                                   9.2.0.4.0            Production

Oracle9i Enterprise Edition                    9.2.0.4.0            64bit Production

PL/SQL                                    9.2.0.4.0            Production

TNS for Solaris:                             9.2.0.4.0            Production

 

 

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          9.2.0.4.0            VALID

Oracle9i Packages and Types      9.2.0.4.0            VALID

Oracle Workspace Manager       9.2.0.1.0            VALID

 

 

Oracle 10.2.0.3的Ora-1461错误

| | Comments (0)

 

发现最近在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错误解决一例

| | Comments (1)

 

大家知道,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.09aad41c.1.60.1257421

  is local tran 1.60.1257421 (hex=01.3c.132fcd)

  insert pending collecting tran, scn=8914343855672 (hex=81b.884c8638)

然后时不时的会提示下面错误:

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.09aad41c.1.60.1257421  collecting       no      WORKGROUP\LIUQING  8914343855672

 

SQL> select * from DBA_2PC_NEIGHBORS;

 

LOCAL_TRAN_ID          IN_      DATABASE        DBUSER_OWNER                   DBID                  SESS# BRANCH

---------------------- --- --------------- ------------------------------ ----------------- ---------- --------------------

1.60.1257421                     in                                       BOSSMGR                             N                                  1            0000

 

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.

 

2Puege(清空)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;

 

 

参考信息/更多阅读:

 

https://metalink.oracle.com

 

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

While Trying to Commit or Rollback a Pending Transaction Getting Errors ORA-02058,ORA-01453,ORA-06512

 

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
standby database ID mismatch [0x99bb1983:0x8d17262b]

 

Metalink的解释:

Symptoms

Standby alert log reports "RFS: Possible network disconnect with primary database"

At the standby DB side I get this error every minute.
RFS: Possible network disconnect with primary database
Standby database ID mismatch [0xAAAA:0xBBBBB]

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.
If found one but not in primary/standby config, disable log_archive_dest_2 to the instance, ie

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.
SQL> select dbid from v$database;

SQL> alter system set log_archive_dest_2_state=defer;

 

 

 

按照上述说明,果然在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的不同状态

| | Comments (2)

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不再有用了。