ITPub博客

oracle日志管理 1.forcing log switches sql> alter system switch logfile; 2.forcing checkpoints sql> alter system checkpoint; 3.adding online redo log groups sql> alter database add logfile [group 4]sql> ('/disk3/log4a.rdo','/disk4/log4b.rdo') size 1m; 4.adding online redo log members sql> alter database add logfile member sql> '/disk3/log1b.rdo' to group 1, sql> '/disk4/log2b.rdo' to group 2; 5.changes the name of the online redo logfile sql> alter database rename file 'c:

DB2 backup fails with SQL2079N return code 30 2005-07-19-15.34.41.479674+480 I5379133C371 LEVEL: Error PID : 430324 TID : 1 PROC : db2med.184372.0 0 INSTANCE: db2inst NODE : 000 FUNCTION: DB2 UDB, database utilities, sqluvintCall, probe:10 MESSAGE : Signal encountered in sqluvint DATA #1 : Hexdump, 4 bytes 0x2FF20D70 : 800F 00AF .... 2005-07-19-15.34.41.480174+480 I5379505C630 LEVEL: Error PID : 430324

db2恢复有关说明 1）、恢复操作也有online和offline的,区别如同backup的操作。 2）、按照表空间的备份和恢复类似，加子句TABLESPACE ( tablespace-name 即可。表空间级别的备份/恢复操作要求数据库处于归档日志和启用增量备份模式下。 3）、恢复的例子中只做了版本恢复。若还有更新的全备份和增量备份的image，可以依次做恢复（注意使用db2ckrst的建议恢复次序和次数）后，再做roll forward. [@more@]

恢复db2 数据库 1）、手工drop数据库，模拟灾难恢复的情况，执行如下操作： db2 drop db sample 2）、恢复备份历史纪录（每次backup，不论类型，都会备份历史纪录文件）。这里的时间戳应该是最新的： db2 restore db sample history file use tsm taken at 20030102223107 buffer 100 3）、使用db2的恢复帮助工具： db2ckrst -d sample -t 20030101224424 -r database 命令返回建议的必需的恢复操作命令。 4）、按照帮助工具的提示，先做版本恢复，恢复命令如下： db2 restore db sample incremental use tsm taken at 20030101224424 buf

设置db2 的在线备份db2 =>update db cfg for sample using userexit on （启用用户出口）db2 =>update db cfg for sample using logretain on （启用归档日志） db2 => update db cfg for sample using trackmod on （启用增量备份功能）db2 =>terminate [@more@]

db2离线全备份 1、离线全备份 1）、首先确保没有用户使用DB2: $db2 list applications for db sample 2）、停掉数据库并重新启动，以便断掉所有连接： db2stop force db2start 3）、执行备份命令：（使用TSM作为备份的介质） db2 backup db sample use tsm 备份成功，将会返回一个时间戳。 4）、检查备份成功： Db2 list history backup all for sample ，可以看到多了这个备份的纪录。 Db2adutl query命令也可以看到返回值。 [@more@]

实体化视图站点脚本 OEM 在设置复制环境中，自动生成的oracle 创建脚本主体站点: AVATAR 实体化视图站点: AUTHAA 管理员: MVADMIN 传播方: MVADMIN 主体站点上要连接的帐户: MVADMIN_AUTHAA 计划连接: AVATAR.COOLYOUNG.COM.CN + 下一日期: SYSDATE + 时间间隔: /*1:Hr*/ sysdate + 1/24 + 延迟秒数: 0 + 遇错停止: FALSE + 并行度: 0 清除调度: + 下一日期: SYSDATE + 时间间隔: /*1:Hr*/ sysdate + 1/24 + 延迟秒数: 0 + 回退段: 方案: + TESTUSER /* 设置实体化视图站点复制环境 */ /* 创建站点 AUTHAA 的复制管理员 */ /* 正在站点 AU

设置主体站点脚本OEM 在设置复制环境中，自动生成的oracle 创建脚本创建repadmin用户脚本具体脚本如下主体站点: AVATAR 管理员: REPADMIN 传播方接收方: REPADMIN 清除调度: + 下一日期: SYSDATE + 时间间隔: /*1:Hr*/ sysdate + 1/24 + 延迟秒数: 0 + 回退段: 要复制的方案:TESTUSER创建复制的脚本/* 设置多主体复制环境 *//* 创建站点 AVATAR 的复制管理员 *//* 正在站点 AVATAR 上创建用户 REPADMIN... */create user "REPADMIN" identified by "REPADMIN"/* 正在站点 AVATAR 上对 REPADMIN 授予管理权限... */BEG

延迟事务无法自动推入处理如果在首次复制过程中，延迟事务无法自动运行，但是手工推入事务，系统又运行成功，这个估计就是复制管理员的数据库的私有链接没有建立。需要创建一个复制管理员的数据库的私有链接。 否则就会出现以下情况，数据库的延迟事务无法自动推入系统在调用sys.dbms_defer_sys.push 的DBMS 时尝试16次后就出现出现中断状态，除非手工推入该延迟事务队列 [@more@]

测试是否能正常访问主体定义站点C:Documents and SettingsAdministrator>sqlplus system/system@avatarSQL*Plus: Release 9.2.0.1.0 - Production on 星期五 1月 20 14:51:04 2006Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.连接到:Oracle9i Enterprise Edition Release 9.2.0.1.0 - ProductionWith the Partitioning, OLAP and Oracle Data Mining optionsJServer Release 9.2.0.1.0 - ProductionSQL> show parameter global_namesNAME TYPE VALUE-------------

高级复制简介复制之前先解释一下复制中的几个概念： 　　1．主站点（Mater Site）：在复制过程中提供数据源的站点。　　2．实体化视图站点（Materialized View Site）：实体化视图复制中的目标站点。　　3．多主体站点复制（Multimaster Replication）：复制环境中的站点都是主站点，对复制的数据库对象有相同的管理权限。　　4．实体化视图复制（Materialized View Replication）： 一个主体站点提供源复制对象，一个实体化视图站点拷贝主站点数据。　　5．实体化视图（Materialized View）：在实体化视图站点为每个复制表或者视图建立一

dbms_logmnr用途日志文件中存放着所有进行数据库恢复的数据，记录了针对数据库结构的每一个变化，也就是对数据库操作的所有DML语句。　　在Oracle 8i之前，Oracle没有提供任何协助数据库管理员来读取和解释重作日志文件内容的工具。系统出现问题，对于一个普通的数据管理员来讲，唯一可以作的工作就是将所有的log文件打包，然后发给Oracle公司的技术支持，然后静静地等待Oracle 公司技术支持给我们最后的答案。然而从8i以后，Oracle提供了这样一个强有力的工具-LogMiner。　　LogMiner 工具即可以用来分析在线，也可以用来分析离线日志文件

安装LogMiner要安装LogMiner工具，必须首先要运行下面这样两个脚本，　　l 、$ORACLE_HOME/rdbms/admin/dbmslm.sql　　2、 $ORACLE_HOME/rdbms/admin/dbmslmd.sql.　　这两个脚本必须均以SYS用户身份运行。其中第一个脚本用来创建DBMS_LOGMNR包，该包用来分析日志文件。第二个脚本用来创建DBMS_LOGMNR_D包，该包用来创建数据字典文件。[@more@]

从spfile二进制文件中产生init.ora文本文件 SQL> SQL> CREATE PFILE='C:init.ora' FROM SPFILE; 文件已创建。 SQL> shutdown; 数据库已经关闭。已经卸载数据库。 ORACLE 例程已经关闭 [@more@]

根据编辑后的init.ora文本文件内容重新生成spfile文件SQL> CREATE SPFILE FROM PFILE='C:init.ora';文件已创建。SQL> STARTUP FORCEORACLE 例程已经启动。Total System Global Area 135338868 bytesFixed Size 453492 bytesVariable Size 109051904 bytesDatabase Buffers 25165824 bytesRedo Buffers 667648 bytes数据库装载完毕。数据库已经打开[@more@]

编辑产生的init.ora文本文件增加归档日志参数段 *.aq_tm_processes=1 *.background_dump_dest='D:oracleadminmyoraclebdump' *.compatible='9.2.0.0.0' *.control_files='D:oracleoradatamyoracleCONTROL01.CTL','D:oracleoradatamyoracleCONTROL02.CTL','D:oracleoradatamyoracleCONTROL03.CTL' *.core_dump_dest='D:oracleadminmyoraclecdump' *.db_block_size=8192 *.db_cache_size=25165824 *.db_domain='' *.db_file_multiblock_read_count=16 *.db_name='myoracle' *.dispatchers='(PROTOCOL=TCP) (SERVICE=myoracleXDB)' *.fast_st

设置oracle数据字典的路径 Sysdba 身份登陆，察看系统参数，察看“utl_file_dir”参数是否添加了路径，如没有，则必须注：都要以sysdba身份登陆执行）打开init.ora文件，加入utl_file_dir=d:oracle(注：改为自己的路径，是logminer使用文件的默认路径),然后应用新的设置打开oracle数据库。修改后的路径，界面显示如下 [@more@]

有条件分析日志EXECUTE dbms_logmnr.start_logmnr( dictfilename => 'd:oracleshwdict.ora',starttime => to_date('2005-8-18 12:15:00','yyyy-mm-dd hh24:mi:ss'), endtime => to_date('2005-8-18 23:40:30','yyyy-mm-dd hh24:mi:ss')); 要注意scn范围和日期格式，格式要与你修改的一样。当然也可以根据其他条件进行分析日志的范围。也可以通过设置起始SCN和截至SCN来限制要分析日志的范围：　　SQL> EXECUTE dbms_logmnr.start_logmnr(　　DictFileName => ' d:oracleshwdict.ora ',　　StartScn => 20,　　EndScn =&

我们可以利用LogMiner日志分析工具来分析其他数据库实例产生的重作日志文件，而不仅仅用来分析本身安装LogMiner的数据库实例的redo logs文件。使用LogMiner分析其他数据库实例时，有几点需要注意1. LogMiner必须使用被分析数据库实例产生的字典文件，而不是安装LogMiner的数据库产生的字典文件，另外必须保证安装LogMiner数据库的字符集和被分析数据库的字符集相同。2. 被分析数据库平台必须和当前LogMiner所在数据库平台一样，也就是说如果我们要分析的文件是由运行在UNIX平台上的Oracle 8i产生的，那么也必须在一个运行在UNIX平台上的Or

终止日志分析事务需要强调一点的是，视图v$logmnr_contents中的分析结果仅在我们运行过程'dbms_logmrn.start_logmnr'这个会话的生命期中存在。这是因为所有的LogMiner存储都在PGA内存中，所有其他的进程是看不到它的，同时随着进程的结束，分析结果也随之消失。　　最后，使用过程DBMS_LOGMNR.END_LOGMNR终止日志分析事务，此时PGA内存区域被清除，分析结果也随之不再存在。[@more@]