删除用户报ORA-24005错误及解决办法

在一套10.2.0.5.0的双节点RAC数据库上,删除用户时报出ORA-00604及ORA-24005的错误:

 
SQL> conn / as sysdba;
Connected.
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production
SQL> drop user gdhytest cascade;
drop user gdhytest cascade
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-24005: must use DBMS_AQADM.DROP_QUEUE_TABLE to drop queue tables
SQL> 

后经查找MetaLink:Ora-24005 Error Trying To Drop User Sysman Cascade [ID 456437.1] 找到原因:被删除的用户ghhytest拥有queue table。

 
SQL> set pagesize 100 
SQL> col object_name format a40 
SQL> select object_name,object_type from dba_objects
  2  where owner='GDHYTEST' AND OBJECT_NAME LIKE '%AQ%'
  3  ;
OBJECT_NAME                              OBJECT_TYPE
---------------------------------------- -------------------
AQ$_GPSSTATUS_QUEUE_TABLE_H              TABLE
AQ$_GPSSTATUS_QUEUE_TABLE_I              TABLE
AQ$_GPSSTATUS_QUEUE_TABLE_NR             TABLE
AQ$_GPSSTATUS_QUEUE_TABLE_T              TABLE
AQ$_GPS_TEMP_QUEUE_TABLE_NR              TABLE
SQL>

解决方法:

1 gdhytest登录数据库,执行DBMS_AQADM.DROP_QUEUE_TABLE进行删除queue talbe:

 
SQL> conn gdhytest/gdhytest
Connected.
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'AQ$_GPSSTATUS_QUEUE_TABLE_H',
force=>true);
BEGIN DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'AQ$_GPSSTATUS_QUEUE_TABLE_H',
force=>true); END;
      *
ERROR at line 1:
ORA-06550: line 1, column 7:
PLS-00201: identifier 'DBMS_AQADM' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored

2 发现权限不够,赋权,重新删除:

 
SQL> conn / as sysdba;
Connected.
SQL> grant dba to gdhytest;
Grant succeeded.
SQL> conn gdhytest/gdhytest
Connected.
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'AQ$_GPSSTATUS_QUEUE_TABLE_H',
force=>true);
BEGIN DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'AQ$_GPSSTATUS_QUEUE_TABLE_H',
force=>true); END;
*
ERROR at line 1:
ORA-24019: identifier for QUEUE_TABLE too long, should not be greater than 24
characters
ORA-06512: at "SYS.DBMS_AQADM_SYS", line 4310
ORA-06512: at "SYS.DBMS_AQADM", line 197
ORA-06512: at line 1
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'GPSSTATUS_QUEUE_TABLE_H',
force=>true);
BEGIN DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'GPSSTATUS_QUEUE_TABLE_H',
force=>true); END;
*
ERROR at line 1:
ORA-24002: QUEUE_TABLE GDHYTEST.GPSSTATUS_QUEUE_TABLE_H does not exist
ORA-06512: at "SYS.DBMS_AQADM_SYS", line 4310
ORA-06512: at "SYS.DBMS_AQADM", line 197
ORA-06512: at line 1

3 依然报错!!!QUEUE_TABLE too long,不得已,重命名queue table进行删除:

 
SQL> rename  AQ$_GPSSTATUS_QUEUE_TABLE_H to queue1;
Table renamed.
SQL> select * from tab;
TNAME                          TABTYPE  CLUSTERID
------------------------------ ------- ----------
AQ$_GPSSTATUS_QUEUE_TABLE_I    TABLE
SYS_IOT_OVER_60452             TABLE
AQ$_GPSSTATUS_QUEUE_TABLE_NR   TABLE
AQ$_GPSSTATUS_QUEUE_TABLE_T    TABLE
SYS_IOT_OVER_60459             TABLE
AQ$_GPS_TEMP_QUEUE_TABLE_NR    TABLE
QUEUE1                         TABLE
7 rows selected.
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'QUEUE1',force=>true);
PL/SQL procedure successfully completed.
SQL> select * from tab;
TNAME                          TABTYPE  CLUSTERID
------------------------------ ------- ----------
AQ$_GPSSTATUS_QUEUE_TABLE_I    TABLE
SYS_IOT_OVER_60452             TABLE
AQ$_GPSSTATUS_QUEUE_TABLE_NR   TABLE
AQ$_GPSSTATUS_QUEUE_TABLE_T    TABLE
SYS_IOT_OVER_60459             TABLE
AQ$_GPS_TEMP_QUEUE_TABLE_NR    TABLE
6 rows selected.
SQL> 
4 如法炮制,重命名其它queue table,然后执行删除:
 
SQL> rename AQ$_GPSSTATUS_QUEUE_TABLE_I to queue_a;
Table renamed.
SQL> rename AQ$_GPSSTATUS_QUEUE_TABLE_NR to queue_b;
Table renamed.
SQL> rename AQ$_GPSSTATUS_QUEUE_TABLE_T to queue_c;
Table renamed.
SQL> rename aq$_GPS_TEMP_QUEUE_TABLE_NR to queue_d;
Table renamed.
SQL> select * from tab;
TNAME                          TABTYPE  CLUSTERID
------------------------------ ------- ----------
SYS_IOT_OVER_60452             TABLE
SYS_IOT_OVER_60459             TABLE
QUEUE_B                        TABLE
QUEUE_A                        TABLE
QUEUE_C                        TABLE
QUEUE_D                        TABLE
6 rows selected.
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'QUEUE_A',force=>true);
PL/SQL procedure successfully completed.
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'QUEUE_B',force=>true);
PL/SQL procedure successfully completed.
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'QUEUE_C',force=>true);
PL/SQL procedure successfully completed.
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'QUEUE_D',force=>true);
PL/SQL procedure successfully completed.
SQL> select * from tab;
no rows selected

5 最后彻底删除gdhytest用户:

 
SQL> conn / as sysdba;
Connected.
SQL> drop user gdhytest cascade;
User dropped.
SQL> 

调试存储过程:ORA-0131 Insufficient privileges 处理

昨天,一开发同事反映说在PL/SQL Developer工具里无法调试存储过程,报错信息如下:

ORA-0131:Insufficient privileges.

Note:Debugging requires the DEBUG CONNECT SESSION system privileges.                                                                                                                                        

后经查找,是缺失  DEBUG CONNECT SESSION 系统权限所致。

解决办法:以SYS用户登录数据库,执行赋权操作:

SQL> grant  DEBUG CONNECT SESSION to user_name;

附1:有网友指出还需赋予DEBUG ANY PROCEDURE的权限,经测试,该权限可不用赋予!

附2:可以从数据字典role_sys_privs表查看该权限相关信息:

SQL> conn / as sysdba;
Connected.
SQL> select * from role_sys_privs where privilege like 'DEBUG%' order by 2;
ROLE             PRIVILEGE                ADM
---------------- ------------------------ ---
DBA              DEBUG ANY PROCEDURE      YES
JAVADEBUGPRIV    DEBUG ANY PROCEDURE      NO
DBA              DEBUG CONNECT SESSION    YES
JAVADEBUGPRIV    DEBUG CONNECT SESSION    NO

简单记录,以作备忘!

知识还是点点记录好!

impdp ORA-31655错误处理一例

今天上午,收到开发同事发过来的邮件:

需要将从之前用EXPDP备份的dump文件中,将某张表还原到一个新的schema下。

电话沟通后,原来是想要将逻辑备份的dump文件中FR8_ZH这个用户下的SB_DATA_RIGHT,导入到同库下的FR8_TEST9这个schema下。

①  于是开始干活:

C:\Documents and Settings\Administrator>impdp directory=my_dump dumpfile=2012-01
-23.dmp logfile=fr8_test9.log remap_schema=fr8_zh:fr8_test9 tables=SB_DATA_RIGHT
Import: Release 10.2.0.5.0 - Production on 星期五, 03 2月, 2012 11:32:53
Copyright (c) 2003, 2007, Oracle.  All rights reserved.
用户名: sys/oracle as sysdba
连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

ORA-31655: 尚未为作业选择数据或元数据对象

已成功加载/卸载了主表 "SYS"."SYS_IMPORT_TABLE_01"

启动 "SYS"."SYS_IMPORT_TABLE_01":  sys/******** AS SYSDBA directory=my_dump dump
file=2012-01-23.dmp logfile=fr8_test9.log remap_schema=fr8_zh:fr8_test9 tables=S
B_DATA_RIGHT

作业 "SYS"."SYS_IMPORT_TABLE_01" 已于 11:33:19 成功完成

发现,报出ORA-31655的错误!!!

SQL> !oerr ora 31655

31655, 00000, "no data or metadata objects selected for job"

// *Cause:  After the job parameters and filters were applied,

//          the job specified by the user did not reference any objects.

// *Action: Verify that the mode of the job specified objects to be moved.

//          For command line clients, verify that the INCLUDE, EXCLUDE and

//          CONTENT parameters were correctly set.  For DBMS_DATAPUMP API

//          users, verify that the metadata filters, data filters, and

//          parameters that were supplied on the job were correctly set.
SQL>

而ORA-31655的错误是说,在导入数据的命令中,impdp没有找到正确的对象元数据。

②  加上INCLUDE关键字,重新执行导入:

 
C:\Documents and Settings\Administrator>impdp directory="my_dump" dumpfile=2012-
01-23.dmp logfile=fr8_test9.log remap_schema=fr8_zh:fr8_test9 tables=SB_DATA_RIG
HT include=table:\"like \'SB_DATA_RIGHT%\'\"
Import: Release 10.2.0.5.0 - Production on 星期五, 03 2月, 2012 11:36:35
Copyright (c) 2003, 2007, Oracle.  All rights reserved.
用户名: sys/oracle as sysdba
连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

ORA-31655: 尚未为作业选择数据或元数据对象
已成功加载/卸载了主表 "SYS"."SYS_IMPORT_TABLE_01"

启动 "SYS"."SYS_IMPORT_TABLE_01":  sys/******** AS SYSDBA directory=my_dump dump
file=2012-01-23.dmp logfile=fr8_test9.log remap_schema=fr8_zh:fr8_test9 tables=S
B_DATA_RIGHT include=table:"like \'SB_DATA_RIGHT%\'
"
作业 "SYS"."SYS_IMPORT_TABLE_01" 已于 11:37:02 成功完成

发现依然报ORA-31655的错误!

③ 不得已,查找Metalink,ORA-31655 On imdp As a Privileged User Wih INCLUDE= After Upgrade To 10.2.0.5/11.2 [ID 1225108.1] 得到下述的解决办法:

Applies to:

Oracle Server – Enterprise Edition – Version: 10.2.0.5 and later   [Release: 10.2 and later ]
Oracle Server – Enterprise Edition – Version: 11.2.0.1.0 to 11.2.0.2.0   [Release: 11.2 to 11.2]
Information in this document applies to any platform.

 

Symptoms

Datapump import raises an ORA-31655 “no data or metadata objects selected for job” on import when using the REMAP_SCHEMA and INCLUDE= clauses when performed as a privileged user (i.e. a user with the IMP_FULL_DATABASE role).

Changes

The database has been upgraded to 10.2.0.5 or 11.2.

Cause

This is intended behavior and occurs due to the fix for bug:6831823 which went in to 11.2 and 10.2.0.5.

The ORA-31655 error is now signaled following the fix for bug:6831823, as that bug which existed in previous versions meant that if a privileged user performed a table import from a full export dump, and the specified table name existed in multiple schemas, then all the tables would be imported where as only the table for the importing user should have been imported, as documented in the Oracle� Database Utilities 10g Release 2 (10.2) manual, chapter 3 ‘Data Pump Import’, under the definition of the TABLES= clause, which states “If you do not supply a schema_name, it defaults to that of the current user”.  This also applies to the INCLUDE= clause, and hence the error is now raised.

Documentation bug:10140472 has been created to get this more clearly stated under the INCLUDE and REMAP_SCHEMA options in future documentation sets.

Solution

Perform the import using the TABLES= clause rather than the INCLUDE=TABLE: clause, e.g.:

 

Change From:

impdp system directory=data_pump_dir dumpfile=scott.dmp remap_schema=scott:scott_test include=TABLE:\”IN \(\’EMP\’, \’DEP\’\)\”

To:

impdp system directory=data_pump_dir dumpfile=scott.dmp remap_schema=scott:scott_test tables=SCOTT.EMP,SCOTT.DEPT

or 

impdp scott directory=data_pump_dir dumpfile=scott.dmp remap_schema=scott:scott_test include=TABLE:\”IN \(\’EMP\’, \’DEPT\’\)\” 

找到问题的原因后,执行下述命令重新导入成功!

 
C:\Documents and Settings\Administrator>impdp directory="my_dump" dumpfile=2012-
01-23.dmp logfile=fr8_test9.log remap_schema=fr8_zh:fr8_test9 tables=fr8_zh.sb_d
ata_right
Import: Release 10.2.0.5.0 - Production on 星期五, 03 2月, 2012 11:48:02
Copyright (c) 2003, 2007, Oracle.  All rights reserved.
用户名: sys/oracle as sysdba
连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

已成功加载/卸载了主表 "SYS"."SYS_IMPORT_TABLE_01"
启动 "SYS"."SYS_IMPORT_TABLE_01":  sys/******** AS SYSDBA directory=my_dump dump
file=2012-01-23.dmp logfile=fr8_test9.log remap_schema=fr8_zh:fr8_test9 tables=f
r8_zh.sb_data_right

处理对象类型 SCHEMA_EXPORT/TABLE/TABLE

处理对象类型 SCHEMA_EXPORT/TABLE/TABLE_DATA

. . 导入了 "FR8_TEST9"."SB_DATA_RIGHT"                 5.328 MB    4484 行

处理对象类型 SCHEMA_EXPORT/TABLE/INDEX/INDEX

处理对象类型 SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT

处理对象类型 SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS

处理对象类型 SCHEMA_EXPORT/TABLE/COMMENT

处理对象类型 SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS

作业 "SYS"."SYS_IMPORT_TABLE_01" 已于 11:48:49 成功完成

最后,登录数据库后,检查FR8_TEST9用户下的SB_DATA_RIGHT表中的数据,发现一切正常。

解决ORA-12516错误一则

在上周五晚上通宵加班将一套10.2.0.5.0的Linux 虚拟机环境下的数据量为260GB 的双节点RAC数据库顺利迁移至一台物理机器的开发数据库后,这两天开发的同事反映说连不上物理机开发库了。

起初,我也没有太在意,的确是因为这两天公司内部网络不太正常,ping物理开发库延时比较严重,偶有timed out现象,就一直以为是网络的问题了。直到中午的时候,同事说网络基本正常了,用PL/SQL Developer客户端工具连数据库的时候报出Ora-12516的错误,这才引起了我的注意!

上Metalink查了一下,看了“Troubleshooting Guide TNS-12519 TNS-12516 ORA-12519 ORA-12516 [ID 552765.1]”的文章后,才知道了自己迁移数据库后粗心大意犯下的错误。原来的RAC数据库中每个实例中都将process初始化参数都设置了400,sessions=445,而现在是单台数据库对外提供服务,导致会话数不够用,最终导致的Ora-12516的错误!其实,对于这种开发库而言,公司的开发同事并不多,怎么可能导致445个会话还不够连接使用呢?其实,造成问题的最根本原因是开发人员的应用程序中的连接池配置的有问题,连接数配置过高导致的!!!!

找到了问题的基本原因后,就将process初始化参数从400改为600,进而sessions自动被置为665,transactions参数自动置为731。然后,重启数据库。

        在oracle数据库的初始化参数中,有一类参数是推倒参数,其中:

        sessions=1.1*processes+5,transactions=1.1*sessions.

这样,问题得到了基本的解决。

事后,又出现了一些不痛不痒的问题。

这不,年后简单记录下发生在这个春节前的种种问题,及解决问题的方法:

① 会话数不够用,导致Ora-12516的错误。解决方法,加大process初始化参数,或者通知修改应用程序中的连接数;

② 通过在数据库端配置profile来控制每个会话的活动时间,过期由数据库自动断开会话;

③ 通过使用共享服务器模式来控制数据库服务器端的进程资源;

④ 最头大的问题就是,有个开发的同事将自己PC机器的IP地址设置了同数据库服务器相同的IP地址,导致其他开发人员一直连接不上数据库!!!这个问题可不是第一次遇见,解决办法,协同网络管理员将数据库服务器IP绑定到MAC。

 

其实,这本来是去年春节前遇到的一则案例,后来由于太忙,赶着要回家,于是拖到了今天才发布出来!

记生平第一次跑完马拉松全程比赛

时间:2012年1月7日

地点:厦门

人物:本人及所有参赛运动员外加广大热心观众

事件:生平第一次参加国际马拉松全程邀请赛

比赛路线图:单击查看

成绩:6时36分12秒

概要:本来应该是早上8点准时开赛的,由于自己没能提前进场,耽误了10分钟,结果8:10分开始比赛。前半程跑起来感觉比较轻松,后半程,尤其是22公里到24公里之间,感觉身体极其疲惫,每迈一步都觉得很吃力,几度想放弃,又几度坚持下来了,过了这两公里的疲劳期之后,感觉身体又缓解了很多,不停地补充能量、水分,慢慢的边跑边走,熬到了30公里处,觉得舒服了很多,想想剩下的10多公里不就是一咬牙的事儿嘛。等看到32公里的标示牌时,那叫一个胜利就在前方不远处!就这样,坚持着,坚持着,不停给自己鼓劲,不放弃,最终于下午2点46分12秒到达厦门国际会议展览中心的全程马拉松终点!

赛后回顾:等跑完全程下来,觉得42.195公里的全程马拉松不过如此而已!难就难在坚持,其实,也就是一咬牙的事儿!虽然我花了6个多小时的时间,那么是否能跑出更好的成绩呢,我给自己的答案是明年厦门国际马拉松全程赛场见!

遗憾:跑完全程下来,让同事帮我到赛委会领取成绩证书,最后,却弄丢了证书。

厦门马拉松官方网站:http://www.xmim.org/cn/

延伸阅读:马拉松的故事,以下内容摘自网络:

马拉松与一场战争有关,马拉松原是一个地名,是波希战争的主战场。现在的马拉松的标准距离是马拉松平原到雅典中心广场的距离——42195米。古代波斯帝国有个名叫大流士一世的国王,到公元前6世纪末,他已经征服了周围许多国家和地区,那时候,波斯军队攻占了东起印度河流域,西至撒哈拉大沙漠的广大地区。剩下最后一个侵略目标就是隔海相望的希腊半岛了。

    公元前500年,希腊人建在小亚细亚西南靠近爱琴海边的米利都城邦,率先起来进行摆脱波斯人统治的斗争。雅典应米利都的请求,与另一城邦爱勒特里亚一起派出25艘战船前往援助。希腊人很快攻陷了波斯在小亚细亚的总督府萨底斯,并放火把它烧了。但终因敌不过强大的波斯军队,米利都最后还是失败了。当初,雅典派战船支援米利都的消息传到波斯都城苏萨时,大流士一世十分震惊。他搭弓向西射了一箭,发誓要向雅典人报仇雪恨。他甚至命令奴仆,在他每次吃饭前都要大呼三声:“皇上!记住雅典人!”
    公元前492年,波斯海陆大军在大流士一世的女婿的率领下,第一次进攻希腊本土。不料,这次出师不利,舰队在阿陀斯海角遭遇大风暴,没有踏入希腊本土。
    大流士一方面继续备战,另方面派使者到希腊各城邦去索取土和水,试探希腊各城邦对波斯的态度,妄想采用外交恐吓的卑劣手段降服希腊人。半岛北部的一些城邦害怕强大的波斯,被迫照做了。只有南部的雅典和斯巴达等城邦顶住压力,坚决拒绝投降。斯巴达人把大流士的使者拖到一口井的旁边,指着井口说:“井里有水又有土,要多少就随便拿吧!”说完,把他投进了井里。
    大流士被彻底地激怒了。他决定派有丰富作战经验的将领率军第二次远征希腊。公元前490年,波斯军横渡爱琴海,波斯军一举攻占了爱勒特里亚。接着,波斯军向南开进,杀向雅典。他们在雅典东北60公里的马拉松平原登陆,打算一举攻占这片土地。波斯军一旦攻占了马拉松,沿着一条大道向东翻越一个山丘,步行几十公里,就可抵达雅典城。
大军压境,雅典面临亡国的威胁。情急之下,雅典人派有名的长跑好手斐利皮德斯到斯巴达请求援兵。可斯巴达推辞说,他们正在过一种节日,按习惯必须等到月亮圆时,才能出兵。
    如果坐等援军,就只有死路一条。雅典人只得依靠自己的力量,保卫自己的国家。他们动员了所有公民,征集到一万名重装兵。此外,还得到普拉提亚派来的一千名援军。雅典军队只有波斯的十分之一,力量对比十分悬殊。在这种不利的形势下,雅典军统帅米太亚得决定不与波斯人硬拼,把所有的士兵集中到马拉松,列成方阵。其中精锐兵力布署在两侧,正面中间部分的兵力相对薄弱。两军接触后,波斯军又施用中间突破的老办法,迫使雅典方阵里的中军向后退却。待气势汹汹的波斯军队追赶雅典中军时,雅典方阵两侧的精锐兵力以迅雷不及掩耳之势,杀向已经拉得很长的波斯军队。毫无准备的波斯军队猝不及防,立即乱了阵容,纷纷逃向海上的战船。雅典军又转向后方与中军联合,围歼了波斯中军,取得了马拉松战役的胜利,共歼灭波斯军6000多人,而雅典仅损失了192名士兵。
    为了把胜利的喜讯尽快地传到雅典城里,米太亚得派跑得快的斐利皮德斯去完成这一任务。斐利皮德斯带着创伤和打仗的疲劳,立即往回飞跑。他以惊人的毅力,一口气跑了40多公里。抵达雅典城中央广场时,他只喊了声:“庆祝吧!雅典得救了!”就倒在地上牺牲了。
    后人为了纪念这件事,决定1896年在雅典举行的第一届奥林匹克运动会上,新设一个竞赛项目,叫马拉松赛跑,距离以当年斐利皮德斯跑过的路程为准。这之后的几届奥运会,马拉松赛跑的距离一直没有统一。1920年,第七届奥运会前夕,人们重新测量了从马拉松到雅典中央广场的距离,才正式定为42公里195米。
     这就是马拉松赛跑的来历。

Oracle OCP考试1z0-007系列2:学会使用WHERE和ORDER BY从句

继上篇日志,Oracle OCP考试1z0-007系列1:学会使用基本的SQL语句后,本篇是系列2,学会使用WHERE和ORDER BY从句。 本篇是1z0-007课程的第二章,主要内容: 1 学会使用WHERE从句从结果集中过滤数据; 2 学会使用ORDER BY从句对结果集进行排序。 本篇内容比较简单,只涉及到WHERE从句和ORDER BY从句两个知识点。 附:具体文档和讲义。

Oracle OCP考试1z0-007系列1:学会使用基本的SQL语句

在上一篇博文里提到Oracle OCP考试1z0-007考试的题库。从本篇开始,将带来Oracle OCP 1z0-007考试的相关文档和资料。

本篇是1z0-007课程的第一章,主要内容:
1 学会使用基本的SQL语句;
2 了解SQL语句的功能;
3 学会如何执行基本的SQL语句
4 了解SQL语句与iSQL*PLUS命令的差别

附:下述是具体文档和讲义。

Oracle OCP考试1z0-007题库

有不少学习Oracle的同学,或者是已经从事Oracle DBA相关工作的职场人士,都想通过Oracle官方考试,获取OCP证书,从而提高自己的技能、含金量。

然而,拥有Oracle OCP证书并不能代表您的Oracle技能水平就与众不同,但是至少对于新入行的DBA来说,证书至少是敲门砖。相比之下,拥有证书的DBA也应该更受雇主青睐。即使,目前市面上到处飘着的都是Oracle OCP,随手一抓就是一大把,我想,我们绝对不可以只做Paper DBA,我们每一个通过自己认真看书、学习、总结、实践,通过自身不断努力,凭借硬实力,而非背题库,最终顺利获取OCP证书的过来人来讲,证书对于我们还是有意义的,即使它只是一张纸而已!

好了,不过多堆砌文字了,奉上经典的Oracle 9i 1z0-007考试的题库,希望可以对即将准备OCP考试的网友们有益。

How to resolve ksvcreate: Process(m000) creation failed

在一套10.2.0.1.0的一主一备dataguard测试环境中,physical standby database的告警日志文件里,经常报出下述错误信息:

Thu Dec  1 08:47:59 2011
alter database open
Thu Dec  1 08:48:00 2011
SMON: enabling cache recovery
Thu Dec  1 08:48:06 2011
Physical standby database opened for read only access.
Completed: alter database open
Thu Dec  1 08:48:11 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:48:38 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:49:38 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:50:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:51:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:52:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:53:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:54:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:55:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:56:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:57:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:58:40 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:59:40 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 09:00:40 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 09:01:41 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 09:02:41 2011
ksvcreate: Process(m000) creation failed

后经查找MetaLink:
‘Ksvcreate: Process(m000) creation failed’ after Standby Database Open Read Only Multiple Times [ID 418553.1]

Applies to:

Oracle Server – Enterprise Edition – Version: 10.2.0.1 to 10.2.0.1 – Release: 10.2 to 10.2
Information in this document applies to any platform.
***Checked for relevance on 15-APR-2011***
Symptoms

Switching a Physical Standby Database multiple to READ ONLY Mode will report the following Errors in the ALERT.LOG:

ksvcreate: Process(m000) creation failed

Changes

Switch Physical Standby from READ ONLY to apply and back to READ ONLY.
Cause

The Cause of this Problem has been identified in Bug 5583049.
Solution

There are two Workarounds available:
Restart the Instance..
or
Disable ADDM – Should be re-enabled if Standby takes up the Primary Role
* Set SGA_TARGET=0 and set shared_pool_size, db_cache_size, etc if using
Automatic SGA Memory Management (ASMM)

* Set STATISTICS_LEVEL=BASIC to disable statistics gathering
References

BUG:5583049 – ‘KSVCREATE: PROCESS(M000) CREATION FAILED’ AFTER STANDBY OPEN RO MULTIPLE TIMES

原来是oracle在10g上的bug,原因是physical standby database在没有完全关闭的情况下多次以read only方式打开。照着Oracle给出的解决方案1,重启Physical standby实例,暂且规避了该错误信息

umount误操作引发数据库宕机

在开发数据库上,执行完其它测试工作后,随手执行命令卸载光盘,图省事,执行了下述命令:

[root@OEL511gR2 ~]# umount -all

然后,然后,就导致了一则不大不小的数据库宕机!!!
因为,我的开发库文件系统信息如下:

[root@OEL511gR2 ~]# df -Th
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/sda1     ext3    9.7G  7.9G  1.3G  87% /
tmpfs        tmpfs    502M     0  502M   0% /dev/shm
/dev/sdb1     ext4     67G   57G  6.5G  90% /u02/rimis_data
172.16.1.100:/backup
               nfs    466G  105G  361G  23% /backup
[root@OEL511gR2 ~]#

而数据库的数据文件信息如下:

[oracle@OEL511gR2 ~]$ rlwrap sqlplus / as sysdba
SQL*Plus: Release 10.2.0.5.0 - Production on Thu Nov 24 17:09:59 2011
Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
/u01/app/oradata/RIMISDB/system01.dbf
/u01/app/oradata/RIMISDB/undotbs01.dbf
/u01/app/oradata/RIMISDB/sysaux01.dbf
/u01/app/oradata/RIMISDB/users01.dbf
/u02/rimis_data/css_ott.dbf
/u02/rimis_data/css_ltt_bk.dbf
/u02/rimis_data/css_lti_bl.dbf
/u02/rimis_data/css_oti.dbf
/u02/rimis_data/css_ltt_rp.dbf
/u02/rimis_data/css_cdi.dbf
/u02/rimis_data/css_lti_ob.dbf
NAME
--------------------------------------------------------------------------------
/u02/rimis_data/css_ltt_eh.dbf
/u02/rimis_data/css_blt.dbf
/u02/rimis_data/css_ltt_bl.dbf
/u02/rimis_data/css_eci.dbf
/u02/rimis_data/css_ect.dbf
/u02/rimis_data/css_lti_ec.dbf
/u02/rimis_data/css_lti.dbf
/u02/rimis_data/css_ltt_gw.dbf
/u02/rimis_data/css_ltt.dbf
/u02/rimis_data/css_ltt_tr.dbf
/u02/rimis_data/css_lti_rp.dbf
NAME
--------------------------------------------------------------------------------
/u02/rimis_data/css_lti_bk.dbf
/u02/rimis_data/css_gwi.dbf
/u02/rimis_data/css_bli.dbf
/u02/rimis_data/css_lti_tr.dbf
/u02/rimis_data/css_ltt_ec.dbf
/u02/rimis_data/css_gwt.dbf
/u02/rimis_data/css_lti_gw.dbf
/u02/rimis_data/css_cdt.dbf
/u02/rimis_data/css_ltt_ob.dbf
/u02/rimis_data/css_lti_eh.dbf
32 rows selected.
SQL>

接着,邮箱就瞬间收到了来自开发项目组发出的数据库不可用的邮件!
最后,重新挂载磁盘,重启数据库。
一个小插曲,启完数据库后,忘记了启监听,就电话通知开发部门数据库可用。
又接着还是一通反应数据库不可用,罪过啊,手工启监听,手工注册服务!
写在这里,给自己提个醒,在服务器上操作时,记得千万千万要谨慎!!!好在,本次故障中,硬盘没损坏!不然就KO了!