nologging插入需再次备份一点分析
相信经常看见文章 blog上面提到用nologging方式插入数据后需要马上进行备份,下面用两个例子来对nologging方式插入后需要再次备份后才能进行完全恢复进行分析. SQL> create table t_nolog01 as select * from dba_objects where 1<>1; Table created SQL> alter table t_nolog01 nologging; Table altered SQL> select table_name,logging from user_tables where table_name='T_NOLOG01'; TABLE_NAME LOGGING -----------------------------
odu的truncate恢复
用老熊的odu又试着做了一下truncate表的恢复,一切都还算很轻松的实现了。 SQL> create table odu_xiaoyu02 as select * from dba_Objects; Table created SQL> insert into odu_xiaoyu02 select * from odu_xiaoyu02; 71940 rows inserted SQL> / 143880 rows inserted SQL> / 287760 rows inserted SQL> / 575520 rows inserted SQL> / 1151040 rows inserted SQL> select count(*) from
odu的drop恢复
找了一个win32的odu测试了一下drop的恢复,odu通过直接读取数据文件抽取数据,确实可以在非常时期解决问题,一则测试用例,大家参考下,详细的odu手册大家可以参考老熊的odu专栏。 SQL> create table odu_xiaoyu01 as select * from dba_objects; Table created SQL> insert into odu_xiaoyu01 select * from odu_xiaoyu01; 71939 rows inserted SQL> insert into odu_xiaoyu01 select * from odu_xiaoyu01; 143878 rows inserted SQL> insert into odu_xiao
主机名导致的ora-00600[keltnfy-1dmInit] [46] [1]
[oracle@wj_gaj_database,localhost admin]$ sqlplus / as sysdbaSQL*Plus: Release 10.2.0.1.0 - Production on Mon Apr 23 21:14:54 2012Copyright (c) 1982, 2005, Oracle. All rights reserved.Connected to an idle instance.SQL> startup nomount;ORA-00600: internal error code, arguments: [keltnfy-ldmInit], [46], [1], [], [], [], [], []警告日志Mon Apr 23 20:57:30 2012Starting ORACLE instance (normal)LICENSE_MAX_SESSION = 0LICENSE_SESSIONS_WARNING = 0Picked latch-free SCN scheme 1Using LOG_ARCHIVE_DEST_10
无备份归档的db意外断电处理-2662和4193
公司生产库崩溃,没有备份和归档,想碰碰运气在mount下利用没有覆盖的redo来recover database,其实还算运气好刚好可以recover然后顺利open db,下面的警告日志中提到了我们经常说的db如何会恢复,db找到corrupted block然后不停的利用redo来恢复,从下面的recover记录中可以看出来Media Recovery Start parallel recovery started with 7 processes并行recovery以及利用redo和archivelog具体恢复信息。SQL> recover database;Media recovery complete.SQL> alter database open;Database altered.警告日志记录:Thu Apr 12 08:54:
闪回和drop原 undo tbs的一点分析
Flashback闪回,表级闪回是由undo回滚段作支撑的(表的结构不能改变,不能alter,truncate等ddl操作),而10g的闪回drop的表是由于表空间的虚拟回收站来闪回的,被删除的表只是被重命名而已,在空间足够情况下并没有彻底清除。而10g的数据库级的闪回则是又闪回日志来支撑的!表级闪回跟undo表空间SQL> select * from xiaoyu.test03; ID---------- 44 11 22 33 44 11 22 33 8 rows selectedSQL> select dbms_flashback.get_system_change_number from dual; GET_SY
深入浅出undo记载03
这里自己无意中做了个测试:之前修改undo表空间为手工管理Sql>alter system set undo_management=manual scope=spfileSql>startup force。。。。。SQL> insert into xiaoyu.test03 select * from xiaoyu.test03; insert into xiaoyu.test03 select * from xiaoyu.test03 ORA-01552: 非系统表空间 'USERS' 不能使用系统回退段SQL> select * from v$rollname; USN NAME---------- ------------------------------ 0 SYSTEM……SQL> show parameter undo; NAME TYPE V
oracle 10g跨越resetlogs恢复-incarnation
Oracle 10g后可以跨越resetlogs恢复数据库,incarnation是跨越resetlogs恢复数据库的重要特性。下面用下列测试来说明下:SQL> create table incarnation_tab01(id number); Table createdSQL> declare 2 begin 3 for i in 1..10 loop 4 insert into incarnation_tab01 select dbms_flashback.get_system_change_number from dual; 5 commit; 6 end loop; 7 end; 8 /PL/SQL procedure successfully completed SQL> select * from incarnation_tab01; ID---------- 1881030 1881031 1881032 1881033
丢失redo的solution
今早打开自己的测试库发现alter system switch logfile无法日志交换,具体问题及解决步骤如下:C:Documents and Settings0990753>sqlplus / as sysdbaSQL*Plus: Release 10.2.0.1.0 - Production on 星期二 12月 20 10:19:34 2011Copyright (c) 1982, 2005, Oracle. All rights reserved.连接到:Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - ProductionWith the Partitioning, OLAP and Data Mining optionsSQL> alter system switch logfile;总是等待,看来日志交换出了问题,查看v$session_wait有event switch
用归档实现无备份下的数据文件恢复和最近学习记载
最近这半个月来自己的学习效率太低了,接下来要好好调整自己,按着自己的习惯去学习,然后最大的还是培养的linux的兴趣,linux上自己虽然已经坚持了快两个月了。但是自己觉得还是完全没有达到自己对oracle的学习习惯,遇到了问题和精彩的知识点总是避开,那是不对的,linux也有丰富的内部世界,同样是一个值得学习的领域,虽然学习我们不可能面面俱到,但是就自己现在对linux的掌握还远远不够,剩下来的三个多月的时间里自己真应该好好抓紧。好了,扯点技术的吧!晚上看pub的一个网友提到了删除了数据文件无备份,但是有归档是否可以恢复.
丢失undo文件和隐含参数_allow_resetlogs_corruption恢复
今早的pub的一个帖子引起了自己的兴趣,说到是错误删除undo表空间数据文件无法打开,此时如果我们有恢复,那直接restore然后recover就行了!模拟下不用备份集恢复的情况吧!关闭数据库在os上删除数据文件13SQL> shutdown abort;数据库已经关闭。已经卸载数据库。ORACLE 例程已经关闭。SQL> startup;ORA-32004: obsolete and/or deprecated parameter(s) specifiedORACLE 例程已经启动。Total System Global Area 524288000 bytesFixed Size 1249968 bytesVariable Size 390073680 bytesDatabase Buf
可传输表空间记载
今天泡pub看到一个网友说到跨平台迁移表空间,把a库的表空间迁移到b库中,往常的可以通过exp和imp或者数据磊工具导入导出,记得在oracle concepts中提到了关于可传输表空间的功能,在oracle 10G中可以跨平台迁移。这里假设a库是源库,b库是目标库select a.platform_name,b.endian_format from v$database a,v$transportable_platform bwhere a.platform_name=b.platform_nameplatform_name endian_format分别在a库和b库这里主要是查看数据库所在的服务器的os上的信息。在oracle 10g的视图Select platform_id,platform_name,endian_forma
rman_copy和基本命令记载
最近这两天终于在linux上装好了oracle 10g,折腾了好多次,有点像自己第一次用pl/sql连接数据库的时候,囧得很啊!不过其中的过程自己倒是对linux的文件目录和vi更加熟悉了。接下来还要配置一下rac和dg的环境,估计又得花一番功夫了!今天又看了eygle的循序渐进,重新翻看了rman的copy备份恢复,试试手了!首先修改一下system01.dbf的位置,方面后面测试Shutdown immediateStartup mount;Alter database rename file to ‘d:system01.dbf’;然后再os上复制数据文件1到的d:、是system.dbf位置Host rman target /Rman>backup as copy da
resetlogs和noresetlogs重建ctl 表空间脱机联机和scn联系
刚开始觉得数据库恢复这部分知识要点还算清楚了,现在觉得以前得有些理解都错了,看来oracle这行还真不能说自己很会,oracle的内部世界可能现在的我根本无法去想象。哎,坚持oracle热爱oracle吧。入门找到属于自己的领地吧!关于表空间和检查点的:表空间脱机Alter tablespace users offline此时将表空间离线将触发检查点,所以此时的控制文件中记录该数据文件检查点Select checkpoint_change# from v$datafile数据文件头部记载的数据文件启动scn也会变化Select checkpoint_change# from v$datafile_header如果此时再进行表空间上线又会触发
rman的全备份脚本和控制文件安全策略
在nocatalog模式下的备份,所有的备份信息都存储在控制文件中,所以数据库的一个完整备份集应该包括数据文件,控制文件,初始化参数文件还有所有的归档日志。Oracle 10G环境rman全备份脚本:rman>run{allocate channedl d1 device type disk;backup full tag ‘orcl’ database include current controlfile plus archivelog delete all input:}在数据库全备份完成之后,需要执行alter system archive log current命令将当前日志归档,备份归档日志应该包括最后生成的归档日志。...RMAN> backup full tag 'orcl' database include c
控制文件快照和rman利用快照恢复
Oracle中有对控制文件快照,windows中默认的存储在oracle_homedatabasesncf<sid>.ora,linux下默认的存储在oracle_home/dbs/snapcf<sid>.ora,这个控制文件快照可以用于数据库恢复。当rman需要同步控制文件信息或者备份当前控制文件时,控制文件快照会自动备份。Rman target /Rman>backup current controlfile format ‘d:control.ctl’;可以查看具体的控制文件和控制文件快照备份信息Windows下直接可以直接查看备份的控制文件属性查看和控制文件快照的默认位置查询。Linux下可以ls查看具体的控制文件备份集和会控制文件快照
rman恢复spfile和control和resetlogs创建控制文件和不完全恢复疑点
这些天太忙了,做的事情好琐碎,不过磨练毅力啊。由于在windows下启动数据库要先启动数据库服务的历程,然后启动数据库cmd>net start oracleserivetest启动数据库服务test历程Cmd>sqlplus sys/oracle as sysdbaStartup一直以为linux也和windows下启动数据库一样,需要启动服务和数据库,今天看eygle在循序渐进书中说到linux下不存在数据库服务这一说话,直接用spfile启动数据库就可以了。也难怪以前在手工创建数据库中提到了oradim,而且此工具只在windows下能使用,是一个注册服务的工具,在linux等平台下无法使用。Oradim –new –
数据库的冷备份迁移
昨天帮网友弄了一下数据库的冷备份然后迁移数据文件 控制文件 日志文件到目标服务器盘符下。1 关闭数据库Sql>Shutdown immediate此时是正常关闭数据库,buffer cache会全部写到数据文件中。2 此时把所有的数据文件 控制文件 日志文件等copy到目标的盘符下Sql>host cp /opt/app/oracle/oradata/test/*.dbf /usr/test/dbCp /opt/app/oracle/oradata/*.log /usr/test/redoCp /opt/app/oracle/oradata/*.ctl /usr/test/ctlcp spfile初始化参数文件到新的oracle_home/dbs/spfiletest.ora此时已经将数据文件 控制文件等物理的copy到新的
rman备份的策略和croosschek delete基本命令
使用rman可以对备份集进行管理,在rman配置中存储的有默认的管理备份集的信息Rman target /Show allRman的配置参数为:Configure retention policy to redundancy 1; #defaultConfigure controlfile autobackup off;…关于rman的备份集得保留策略有基于redundancy冗余和基于reocovery window恢复窗口的保留策略。此时用rman做两个全备份集Rman>run{Allocate channel d1 type disk;Backup database target=full01_test0822;}Rman>rman{Allocate channel d2 type disk;Backup database target=full02_test0822;}此时完成了一个库的两个
意外删除redo的恢复
今天做了点删除redo log的测试,查阅资料和实际动手整理了一下的一些东西。A非当前联机日志被删除损坏正常关闭数据库shutdown immediate我们在os上删除logfile redo01.log,此redo log属于group 1 startup mount;startup;select * from v$logv$log视图中有column status和archived log,其中status有current当前日志组,inactive非活动日志组,active活动日志组,unused未使用日志组,archived表示是否已经归档。当然如果是当前日志组,oracle是不会对其归档的。如果此时我们删除的是非当前日志redo01.log,redo01.log已经归档了,此时启