标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-600 kcratr_nab_less_than_odr ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle碎片 OSD-04016 YOUR FILES ARE ENCRYPTED 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,884)
- DB2 (22)
- MySQL (82)
- Oracle (1,709)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (73)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (662)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- 记录19c ASM磁盘掉线触发ORA-59048故障处理
- aix平台Oracle数据库由于断电无法启动故障处理
- 断电引起ORA-600 3005故障处理
- 记录一次云存储资源到期之后引起的数据库恢复
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
分类目录归档:数据库
清除掉shared pool中某条sql语句方法
在论坛中看到一个帖子,如何清除掉shared pool中某条sql语句,如果是在10g以前的版本,那估计会比较麻烦,为了删除一条sql语句记录,需要清空整个shared pool,在10g中提供了新的dbms_shared_pool包可以实现该功能(如果该包没有安装,可以通过?/rdbms/admin/dbmspool.sql安装),下面我通过在11g中试验证明该问题
1.数据库版本信息
SQL> select * from v$version; BANNER ---------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production PL/SQL Release 11.2.0.1.0 - Production CORE 11.2.0.1.0 Production TNS for 32-bit Windows: Version 11.2.0.1.0 - Production NLSRTL Version 11.2.0.1.0 - Production
2.模拟一条sql语句
SQL> create table xff as
2 select * from dba_tables
3 where rownum<10;
表已创建。
SQL> select count(*) from xff;
COUNT(*)
----------
9
SQL> col sql_text for a30
SQL> SELECT ADDRESS,HASH_VALUE,SQL_TEXT FROM V$SQLAREA
2 WHERE SQL_TEXT LIKE 'select % xff';
ADDRESS HASH_VALUE SQL_TEXT
-------- ---------- ------------------------------
1EFB91B8 3642190903 select count(*) from xff
3.打破神话一:权限操作
对表进行权限操作,可以清除该表在shared pool中关于该表记录
SQL> grant select on xff to chf; 授权成功。 SQL> col sql_text for a30 SQL> SELECT ADDRESS,HASH_VALUE,SQL_TEXT FROM V$SQLAREA 2 WHERE SQL_TEXT LIKE 'select % xff'; ADDRESS HASH_VALUE SQL_TEXT -------- ---------- ------------------------------ 1EFB91B8 3642190903 select count(*) from xff SQL> revoke select on xff from chf; 撤销成功。 SQL> col sql_text for a30 SQL> SELECT ADDRESS,HASH_VALUE,SQL_TEXT FROM V$SQLAREA 2 WHERE SQL_TEXT LIKE 'select % xff'; ADDRESS HASH_VALUE SQL_TEXT -------- ---------- ------------------------------ 1EFB91B8 3642190903 select count(*) from xff
证明grant和revoke操作没有清除shared pool中关于该表的sql语句
4.打破神话二:ddl操作
对表进行ddl操作,可以清除该表在shared pool中关于该表记录
SQL> alter table xff add owner1 varchar2(100); 表已更改。 SQL> SELECT ADDRESS,HASH_VALUE,SQL_TEXT FROM V$SQLAREA 2 WHERE SQL_TEXT LIKE 'select % xff'; ADDRESS HASH_VALUE SQL_TEXT -------- ---------- ------------------------------ 1EFB91B8 3642190903 select count(*) from xff
事实证明ddl操作不能达到预期效果,没有清除掉这条sql语句
5.刷新shared pool
SQL> alter system flush shared_pool 2 ; 系统已更改。 SQL> SELECT ADDRESS,HASH_VALUE,SQL_TEXT FROM V$SQLAREA 2 WHERE SQL_TEXT LIKE 'select % xff'; 未选定行
把整个shared pool都刷新了,自然其中的一条sql语句也没有了,在10g前只能通过这种方法实现
6.使用dbms_shared_pool.purge
SQL> select count(*) from xff;
COUNT(*)
----------
9
SQL> SELECT ADDRESS,HASH_VALUE,SQL_TEXT FROM V$SQLAREA
2 WHERE SQL_TEXT LIKE 'select % xff';
ADDRESS HASH_VALUE SQL_TEXT
-------- ---------- ------------------------------
1EFB91B8 3642190903 select count(*) from xff
SQL> exec dbms_shared_pool.purge('1EFB91B8, 3642190903','C');
PL/SQL 过程已成功完成。
SQL> SELECT ADDRESS,HASH_VALUE,SQL_TEXT FROM V$SQLAREA
2 WHERE SQL_TEXT LIKE 'select % xff';
未选定行
试验证明在shared pool中清除了一条sql记录
7.关于dbms_shared_pool.purge参数说明
purge(name varchar2, flag char DEFAULT 'P', heaps number DEFAULT 1);
-- name
-- The name of the object to keep. There are two kinds of objects:
-- PL/SQL objects, triggers, sequences, types and Java objects,
-- which are specified by name, and
-- SQL cursor objects which are specified by a two-part number
-- (indicating a location in the shared pool). For example:
-- dbms_shared_pool.keep('scott.hispackage')
-- will keep package HISPACKAGE, owned by SCOTT. The names for
-- PL/SQL objects follows SQL rules for naming objects (i.e.,
-- delimited identifiers, multi-byte names, etc. are allowed).
-- A cursor can be keeped by
-- dbms_shared_pool.keep('0034CDFF, 20348871', 'C')
-- The complete hexadecimal address must be in the first 8 characters.
-- The value for this identifier is the concatenation of the
-- 'address' and 'hash_value' columns from the v$sqlarea view. This
-- is displayed by the 'sizes' call above.
-- Currently 'TABLE' and 'VIEW' objects may not be keeped.
--
-- flag
-- This is an optional parameter. If the parameter is not specified,
-- the package assumes that the first parameter is the name of a
-- package/procedure/function and will resolve the name. Otherwise,
-- the parameter is a character string indicating what kind of object
-- to keep the name identifies. The string is case insensitive.
-- The possible values and the kinds of objects they indicate are
-- given in the following table:
-- Value Kind of Object to keep
-- ----- ----------------------
-- P package/procedure/function
-- Q sequence
-- R trigger
-- T type
-- JS java source
-- JC java class
-- JR java resource
-- JD java shared data
-- C cursor
-- If and only if the first argument is a cursor address and hash-value,
-- the flag parameter should be set to 'C' (or 'c').
--
-- heaps
-- heaps to purge. e.g if heap 0 and heap 6 are to be purged.
-- 1<<0 | 1<<6 => hex 0x41 => decimal 65. so specify heaps=>65.
-- Default is 1 i.e heap 0 which means the whole object will be purged.
ORA-600[4194]/[4193]解决
朋友的库启动的时候出现ORA-600[4194]/[4193]错误
Tue Feb 14 09:34:11 2012 Errors in file d:\oracle\product\10.2.0\admin\interlib\bdump\interlib_smon_2784.trc: ORA-01595: error freeing extent (2) of rollback segment (3)) ORA-00607: Internal error occurred while making a change to a data block ORA-00600: internal error code, arguments: [4194], [6], [30], [], [], [], [], [] Tue Feb 14 09:35:34 2012 Errors in file d:\oracle\product\10.2.0\admin\interlib\udump\interlib_ora_2824.trc: ORA-00603: ORACLE server session terminated by fatal error ORA-00600: internal error code, arguments: [4193], [2005], [2008], [], [], [], [], [] ORA-00600: internal error code, arguments: [4193], [2005], [2008], [], [], [], [], [] Tue Feb 14 09:36:30 2012 DEBUG: Replaying xcb 0x1fa24174, pmd 0x1fba06d4 for failed op 8 Doing block recovery for file 2 block 177 No block recovery was needed Tue Feb 14 09:37:30 2012 Errors in file d:\oracle\product\10.2.0\admin\interlib\bdump\interlib_pmon_2732.trc: ORA-00600: internal error code, arguments: [4193], [2005], [2008], [], [], [], [], [] Tue Feb 14 09:37:31 2012 Errors in file d:\oracle\product\10.2.0\admin\interlib\bdump\interlib_pmon_2732.trc: ORA-00600: internal error code, arguments: [4193], [2005], [2008], [], [], [], [], []
从这里可以看到出现了ORA-600[4194]/[4193],第一感觉就是undo出现问题。
4193:表示undo和redo不一致(Arg [a] Undo record seq number,Arg [b] Redo record seq number );
4194:表示也是undo和redo不一致(Arg [a] Maximum Undo record number in Undo block,Arg [b] Undo record number from Redo block)
至于为什么有时候会只出现其中一个,我不太清楚,求答案
直接设置了下面参数,数据库就意外的open成功,这位朋友比较幸运
undo_tablespace=SYSTEM undo_management=MANUAL
既然库已经open,然后新建undo空间,删除出问题的undo,做如下修改,数据库恢复完成
undo_tablespace=新undo undo_management=AUTO
如果出现极端的情况可能需要做如下处理:
1.使用_offline_rollback_segments和_corrupted_rollback_segments屏蔽掉有问题的undo segment
2.继续可能出现ora-600[2662],需要推进scn
Query Duration=0与ORA-01555
1.ALERT日志错误
奇怪之处:Query Duration=0 sec,竟然出现了ORA-01555
Tue Feb 7 02:41:34 2012 ORA-01555 caused by SQL statement below (Query Duration=0 sec, SCN: 0x0b2e.efcd78a9): Tue Feb 7 02:41:34 2012 SELECT "ID_NO","CUST_ID" FROM "DBACCADM"."DCUSTMSG" "C" WHERE "ID_NO"=:1
2.ORA-01555解释
超过了undo_retention时间,undo被覆盖导致ORA-01555
[zwq_acc1:/home/oraeye/check]oerr ora 1555 01555, 00000, "snapshot too old: rollback segment number %s with name \"%s\" too small" // *Cause: rollback records needed by a reader for consistent read are // overwritten by other writers // *Action: If in Automatic Undo Management mode, increase undo_retention // setting. Otherwise, use larger rollback segments
3.数据库版本
SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production PL/SQL Release 9.2.0.8.0 - Production CORE 9.2.0.8.0 Production TNS for IBM/AIX RISC System/6000: Version 9.2.0.8.0 - Production NLSRTL Version 9.2.0.8.0 - Production
4.undo基本信息
从这里可以发现,两个节点的undo表空间还有很多剩余,缺发生了undo被覆盖从而出现了ORA-01555
SQL> col name for a20
SQL> col value for a15
SQL> SELECT INST_ID, NAME, VALUE
2 FROM GV$PARAMETER
3 WHERE UPPER (Name) LIKE '%UNDO%';
INST_ID NAME VALUE
---------- -------------------- ---------------
1 undo_management AUTO
1 undo_tablespace UNDOTBS1
1 undo_suppress_errors FALSE
1 undo_retention 1800
2 undo_management AUTO
2 undo_tablespace UNDOTBS2
2 undo_suppress_errors FALSE
2 undo_retention 1800
8 rows selected.
TABLESPACE_NAME CURRENT_TOTAL(MB) USED(MB) FREE(MB) FREE% AUT MAX_TOTAL(MB)
------------------------------ ----------------- ---------- ---------- ---------- --- -------------
UNDOTBS1 40950 1587.94 39362.0625 96.12 NO 40950
UNDOTBS2 57330 1926.31 55403.6875 96.64 NO 57330
SQL> SELECT DISTINCT STATUS ,
2 COUNT(*) "EXTENT_NUM",
3 SUM(BYTES) / 1024 / 1024 / 1024 "UNDO(G)"
4 FROM DBA_UNDO_EXTENTS
5 GROUP BY STATUS;
STATUS EXTENT_NUM UNDO(G)
--------- ---------- ----------
ACTIVE 208 .273658752
EXPIRED 7651 2.42865753
UNEXPIRED 941 .752548218
查询MOS[ID 761128.1],发现可能是Oracle bug导致(BUG:6799685 – ORA-1555 ERROR WITH QUERY DURATION=0 AND UNDO_RETENTION=1800和BUG:5475085 – V$UNDOSTAT.EXPBLKREUCNT IS NEVER INCREMENTED)
5.解决方法
Increase the size of the UNDO tablespace and increase the UNDO_RETENTION parameter value to try to prevent required undo expiring too quickly.
基于本库,因为undo空间还有很大剩余,直接设置UNDO_RETENTION=3600即可(可以从一定程度上缓解整个问题,但是要从根本上解决整个问题,需要升级到10.2.0.4及其以上版本)

加我微信(17813235971)
加我QQ(107644445)

