[20141218]误操作删除dual表的恢复.txt

[20141218]误操作删除dual表的恢复.txt

--没事，做一个误操作删除dual表的恢复，没想到不能按照网上介绍的方法恢复，做一个记录。

1.建立测试数据库:

mkdir -p /mnt/ramdisk
mount -t tmpfs -o size=8G tmpfs /mnt/ramdisk

$ORACLE_HOME/bin/dbca -createDatabase -templateName General_Purpose.dbc -gdbName test -sid test -sysPassword oracle \
-systemPassword oracle -storageType FS -characterSet ZHS16GBK -nationalCharacterSet AL16UTF16 -listeners LISTENER -sampleSchema  true --memoryPercentage 2 \
-databaseType MULTIPURPOSE -silent -datafileDestination /mnt/ramdisk

--以上是10g静态建立数据库的脚本,与11g有一些不同。

SYS@test> @ &r/ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- ----------------------------------------------------------------
x86_64/Linux 2.4.xx            10.2.0.4.0     Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi

--删除dual表，会导致应用出错，因为许多应用要执行select  sysdate from dual的命令，如果重启，在open阶段就要访问
--dual ,导致无法打开数据库。注意，千万不要在生产系统做这样的测试!!

1.首先抽取dual的定义:
SYS@test> @ &r/ddl sys.dual
C100
--------------------------------------------------------------------------
  CREATE TABLE "SYS"."DUAL"
   (    "DUMMY" VARCHAR2(1)
   ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
  STORAGE(INITIAL 16384 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "SYSTEM" ;

---
CREATE OR REPLACE PUBLIC SYNONYM DUAL FOR SYS.DUAL;
GRANT SELECT ON SYS.DUAL TO PUBLIC WITH GRANT OPTION;

--Insert into SYS.DUAL (DUMMY) Values ('X');
--COMMIT;

2.开始测试:
SYS@test> drop table sys.dual purge ;
Table dropped.

CREATE TABLE "SYS"."DUAL"
(    "DUMMY" VARCHAR2(1)
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 16384 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "SYSTEM" ;

--报如下错误:
CREATE TABLE "SYS"."DUAL"
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01775: looping chain of synonyms

--按照网上的介绍这样应该可以的，难道要删除同义词吗？
SYS@test> drop PUBLIC SYNONYM DUAL;
drop PUBLIC SYNONYM DUAL
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01775: looping chain of synonyms

--问题依旧！做一个跟踪看看:

SYS@test> @ &r/10046on 12
Session altered.

=====================
PARSING IN CURSOR #15 len=275 dep=0 uid=0 oct=1 lid=0 tim=1385609730197333 hv=9179637 ad='76a61078'
CREATE TABLE "SYS"."DUAL"
(    "DUMMY" VARCHAR2(1)
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 16384 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "SYSTEM"
END OF STMT
PARSE #15:c=0,e=1549,p=0,cr=2,cu=0,mis=1,r=0,dep=0,og=1,tim=1385609730197329
BINDS #15:
=====================
PARSE ERROR #24:len=94 dep=1 uid=47 oct=3 lid=47 tim=1385609730197782 err=1775
select dummy from dual where  ora_dict_obj_type = 'SYNONYM' AND ora_dict_obj_owner = 'PUBLIC'
EXEC #15:c=1000,e=461,p=0,cr=0,cu=3,mis=0,r=0,dep=0,og=1,tim=1385609730197891
ERROR #15:err=604 tim=1191228612
WAIT #15: nam='SQL*Net break/reset to client' ela= 2 driver id=1650815232 break?=1 p3=0 obj#=49815 tim=1385609730198202
WAIT #15: nam='SQL*Net break/reset to client' ela= 54 driver id=1650815232 break?=0 p3=0 obj#=49815 tim=1385609730198280
WAIT #15: nam='SQL*Net message to client' ela= 1 driver id=1650815232 #bytes=1 p3=0 obj#=49815 tim=1385609730198306
WAIT #15: nam='SQL*Net message from client' ela= 9676395 driver id=1650815232 #bytes=1 p3=0 obj#=49815 tim=1385609739874747
=====================

--可以发现在建立过程中就要访问dual表。select dummy from dual where  ora_dict_obj_type = 'SYNONYM' AND ora_dict_obj_owner = 'PUBLIC'。

3.开始按照网上的介绍开始恢复。
建立pfile，加入参数replication_dependency_tracking = FALSE。

SYS@test> create pfile='/tmp/test001.ora' from spfile ;
File created.

SYS@test> shutdown immediate ;
Database closed.
Database dismounted.
ORACLE instance shut down.

SYS@test> startup pfile=/tmp/test001.ora
ORACLE instance started.

Total System Global Area    473956352 bytes
Fixed Size                    2084776 bytes
Variable Size               176160856 bytes
Database Buffers            285212672 bytes
Redo Buffers                 10498048 bytes
Database mounted.
Database opened.

SYS@test> show parameter track
NAME                                 TYPE     VALUE
------------------------------------ -------- -------
replication_dependency_tracking      boolean  FALSE

CREATE TABLE "SYS"."DUAL"
(    "DUMMY" VARCHAR2(1)
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 16384 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "SYSTEM" ;

CREATE TABLE "SYS"."DUAL"
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01775: looping chain of synonyms

--依旧报错!跟踪发现依旧要访问select dummy from dual where  ora_dict_obj_type = 'SYNONYM' AND ora_dict_obj_owner = 'PUBLIC';

4.不行，采用升级方式：
SYS@test> startup upgrade pfile=/tmp/test001.ora
ORACLE instance started.
Total System Global Area    473956352 bytes
Fixed Size                    2084776 bytes
Variable Size               176160856 bytes
Database Buffers            285212672 bytes
Redo Buffers                 10498048 bytes
Database mounted.
Database opened.

CREATE TABLE "SYS"."DUAL"
(    "DUMMY" VARCHAR2(1)
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 16384 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "SYSTEM" ;

Table created.
---
Insert into SYS.DUAL (DUMMY) Values ('X');
COMMIT;

SYS@test> select object_type,owner from dba_objects where object_name='DUAL';
OBJECT_TYPE         OWNER
------------------- ------
TABLE               SYS
SYNONYM             PUBLIC

--同义次没有删除，无需建立
--CREATE OR REPLACE PUBLIC SYNONYM DUAL FOR SYS.DUAL;
GRANT SELECT ON SYS.DUAL TO PUBLIC WITH GRANT OPTION;

SYS@test> GRANT SELECT ON SYS.DUAL TO PUBLIC WITH GRANT OPTION;
Grant succeeded.

--ok,恢复完成。使用spfile参数启动数据库。
--我google许多blog，都没有使用startup upgrade pfile=/tmp/test001.ora来解决的，难道我的测试数据库按照了什么特殊组件吗？

时间： 2024-10-10 08:11:03

[20141218]误操作删除dual表的恢复.txt的相关文章

[20160721]rman与undo表空间备份.txt

[20160721]rman与undo表空间备份.txt --//UNDO表空间主要用于存储前镜像数据,这些数据在回滚以及恢复过程中可能被用到. --//一般生产数据库的UNDO表空间可能会变得非常巨大,甚至包括多个数据文件,而备份完整的UNDO数据文件在恢复时一般可能用到的比 --//例很小.所以UNDO的很大一部分备份是多余的,在Oracle11g中,Oracle引入了一个新的特性RMAN UNDO备份优化. --//在RMAN备份UNDO表空间时,提交事务的UNDO信息将不再备份,这个特性

[20130425]删除分区与recycle bin.txt

[20130425]删除分区与recycle bin.txt http://mwidlake.wordpress.com/2012/01/24/dropped-partitions-do-not-go-in-the-recycle-bin/ 昨天别人删除一个分区,想恢复里面的信息.我想删除就是一个段,使用flashback drop应该可以恢复.对方讲不行,自己感觉奇怪,做一个测试看看. 1. 建立测试环境: SQL> @ver BANNER --------------------------

Oracle基于用户管理的不完全恢复（二）恢复过去某个时间点误操作的表

案例1--恢复过去某个时间点误操作的table 1.基于时间点 SQL> select username,scn,timestamp,sql_redo from v$logmnr_contents where seg_name='TB01'; USERNAME               SCN TIMESTAMP           SQL_REDO --------------- ---------- ------------------- -------------------------

9i新特性之Flashback Query的应用-------------针对DML误操作的恢复(2)

恢复 用DBMS_FLASHBACK包   DBMS_FLASHBACK 包提供了以下几个函数:   ENABLE_AT_TIME:设置当前SESSION 的闪回查询时间 ENABLE_AT_SYSTEM_CHANGE_NUMBER:设置当前SESSION的闪回查询SCN GET_SYSTEM_CHANGE_NUMBER:取得当前数据库的SCN       DISABLE:关闭当前SESSION 的闪回查询       如: SQL> select dbms_flashback.get_syst

9i新特性之Flashback Query的应用-------------针对DML误操作的恢复(1)

恢复  9i新特性之Flashback Query的应用-------------针对DML误操作的恢复   作者:刘颖博 时间:2003-12-29 mail:liuyingbo@126.com,请指正   转载请注明出处及作者   在9i之前,如果出现DML的误操作,只能通过备份来完成基于时间点的恢复,9i给提供了一个新的特性Flashback Query,我们可以应用此特性,可以很方便的实现恢复.但是要注意的是,Flashback Query 仅仅是一个查询的机制,不会真正的UNDO任何数

SQLServer 2008以上误操作数据库恢复方法——日志尾部备份

原文:SQLServer 2008以上误操作数据库恢复方法--日志尾部备份 原文出处:http://blog.csdn.net/dba_huangzj/article/details/8491327 问题:          经常看到有人误删数据,或者误操作,特别是update和delete的时候没有加where,然后就喊爹喊娘了.人非圣贤孰能无过,做错可以理解,但不能纵容,这个以后再说,现在先来解决问题.         遇到这种情况,一般都是没有做备份,不然也不会来发问了.首先要冷静,否则会

【MySQL】恢复误操作的方法

一 .前言 本周接二连三的出现开发人员在测试环境和生产误操作导致数据库误删除/更新,对DBA而言,回滚数据着实是一件头疼的事情,凡涉及到恢复线上数据必然对应用带来一定的影响.大多数情况是开发误操作delete数据,update多数行,根据之前的操作经验,本文介绍常用的恢复方法. 写本文的时候 Monogdb 也被曝出有被利用安全漏洞,数据被删除了,希望各位DBA/安全相关人员及时查看自己负责的业务数据库安全相关问题,保护好自己的数据. 二.常用的恢复方式 2.1 利用备份恢复 使用这种方式的前提

MySQL误操作后怎么恢复数据？MySQL误操作后快速恢复数据的教程

摘要: 利用binlog闪回误操作数据. 基本上每个跟数据库打交道的程序员(当然也可能是你同事)都会碰一个问题,MySQL误操作后如何快速回滚?比如,delete一张表,忘加限制条件,整张表没了.假如这还是线上环境核心业务数据,那这事就闹大了.误操作后,能快速回滚数据是非常重要的. 传统解法 用全量备份重搭实例,再利用增量binlog备份,恢复到误操作之前的状态.然后跳过误操作的SQL,再继续应用binlog.此法费时费力,不值得再推荐. 利用binlog2sql快速闪回 首先,确认你的MySQ

利用事务日志来恢复Update、Delete误操作引起的数据丢失

恢复|数据 可能有不少朋友遇到过这样的问题:update或delete语句忘带了where子句,或where子句精度不够,执行之后造成了严重的后果,这种情况的数据恢复只能利用事务日志的备份来进行,所以如果你的SQL没有进行相应的全库备份或不能备份日志(truncate log on checkpoint选项为1),那么就无法进行数据的恢复了,或者只能恢复到最近一次的备份的数据了. 以下简单说明恢复数据方法:1,如果误操作之前存在一个全库备份(或已有多个差异备份或增量备份),首先要做的事就是进进行