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

过年回家,水土不服

| | Comments (4)

大过年的,回家居然连续上起火来,在家呆了一周搞得鼻子嘴巴都烂了,回北京后不得已只好带个口罩"遮丑"。身体不爽,也懒得动笔了。

大家都说我回家水土不服了,晕倒 ^_^

其实我不是水土不服,这一点俺家的那只 大笨狗 可以证明,一年不见了,它见到偶还是那么亲切,老远的就摇着尾巴跑过来亲热。

追究上火之原因,也就是在家熬夜、暴饮暴食的缘故了。还有一条就是喝酒所致。

回到家老妈每到吃饭就会说我瘦,要多吃点,本来可以吃一碗米饭(我们家的碗挺大的),老妈一定要"逼"着我吃一碗半,然后又会给夹好多菜。我是个孝顺而且听话的儿子,每到这个时候我就会主动请缨,"妈,我要吃两碗饭",妈妈听了后就会比较高兴。我直到吃到肚皮"圆"了为止,呵呵 ^_^ 

在父母眼里,孩子永远都是孩子,天下父母心啊!

还要非常感谢我的女友,回到北京后,每天做好多青菜吃,还有泡蜂蜜水喝,上火症状很快消去,伤口也很快长好了!

母亲和女友,她们爱我的方式是不一样的,但她们都是我最爱的女人!

 

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

 

有钱没钱回家过年

| | Comments (7)

《有钱没钱回家过年》

有钱没钱回家过年
我知道你想衣锦把家还
有钱没钱回家过年
家里总有年夜饭......

 

回家过年------对于漂泊在外的游子来说,家是最温暖的字眼;对于在外地务工的农民工来说,远离都市的老家是他们可以避风躲雨的港湾,能够在春节的时间回家过年,同一家老小团聚更是大家最大的期盼。

 

今年游子们归家的路,似乎格外漫长。中国南方大部分省份遭受到了百年不遇的大雪及恶劣天气。水路、公路、铁路、航空,都相继受到了影响,阻断了很多旅客回家过春节的路。一时间,广州、长沙、上海、武汉等交通枢纽站滞留了大量的乘客,人们开始为了回家而焦急地等待着,寻找着各种回家的路。

guangzhou.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

bus.jpg

 

 

 

 

 

 

 

 

 

 

 

 

tiaofu.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

雪灾也给很多地方带来很大的经济损失,并给人民的日常生活带来了很大不便,因为冰雪压断了电缆,压塌了电塔基座:

全国大部分省份开始电力供应紧张.......

贵阳火车站停电,导致火车不能开出......

湖南郴州已停电停水8......