ITPub博客

开发公司根据业务的需要，在本地创建了大量的使用dblink方式去访问远程数据库的数据的SYNONYM（同义词），其实，本地业务用户通过dblink可以访问远程数据库的同义词，如：select * from a.table@dblink ，这样是可以访问的，但是，不幸的是，将同义词放在PROCEDURE里就不行，编译不过去，报错PL/SQL:ORA-04063.metalink给出了答案:[@more@]SELECT From a VIEW in a READ ONLY Database Using a DATABASE LINK Within A CURSOR LOOP Fails With ORA-06550 ORA-04063 PLS-00341 PLS-00364 [ID 358708.1]Applies to: PL/SQL - Version 8.1.7.

GoldenGate实施完之后，运行了一段时间，由于业务上的需求，需要增加一些新表进行同步数据，可以采用新建extract进程或使用旧的extract进程来追加同步新增加的表的数据，我这里采用的是追加的方式进行数据的抽取。[@more@]下面是追加新增加表的操作过程：OGG版本:OGG_for_unix_11g （V26188-01.zip）数据库版本:9.2.0.5（源端）、11.2.0.2（目标端）源端操作：GGSCI>info er *各个进程都正常运行（running）1.增加表级附加日志GGSCI>dblogin userid ggfwzk@fdzy1, password sdb2$fwzk GGSCI>ADD TRANDATA GFPZ.GF_RENTBOUCHER_TA

SYSTEM 版本：/IBM POWER 7/AIX 6.1 64bit/ 内存120G/ CPU16*4 /DATABASE 版本：11.2.0.3GI INFRASTRUCTURE CLUSTER版本： 11.2.0.3PSU（Patch Set Update）版本：最新的11.2.0.3.4下面是打PSU(Patch Set Update)全过程[@more@]一.说明: 1 下面的操作是在完成了GI INFRASTRUCTURE 的安装、DB DATABASE的安装、ASM的创建、DBCA建库的情况下进行的手动滚动升级（rolling patch）的过程.PSU README说明:GI PSU patches can be installed in an Oracle RAC rolling fashion. 如何进行滚动升级、查看方式也可查看DBARoad的《What is rolling pa

当你无法使用deinstall删除grid的时候，使用手动的方式删除grid软件环境：oracle 11.2.0.3 racaix 6.1 [@more@]MeTalink：How to Deinstall Oracle Clusterware Home Manually [ID 1364419.1]Applies to: Oracle Server - Enterprise Edition - Version 10.2.0.1 and laterInformation in this document applies to any platform.GoalIn 11gR2, deinstall is the recommended tool to deinstall an Oracle Clusterware(Grid Infrastructure) home, however it does not apply to certain scenarios or fails in some cases. This notes pr

安装oracle 11.2.0.3 ，安装成功grid,oracle,创建数据库之后，下面进行对rac数据库的完全删除：[@more@]1.dbca删除数据库2.在节点1 ，使用grid用户deinstall/u01/app/11.2.0/grid/deinstall/./deisntallChecking for required files and bootstrapping ...Please wait ...Location of logs /u01/app/oraInventory/logs/############ ORACLE DEINSTALL & DECONFIG TOOL START ##################################### CHECK OPERATION START ########################### [START] Install check configuration ##Checking for existence

shutdown -Fr重启IMB小机之后，使用xmanger工具telnet小机，可以打开telent,但是大约40多秒之后，才能登陆到机器，重启之前，telnet打开就能登陆。[@more@]原因是：该台小型机配置了DNS服务，而且该服务并没有随机器重启而重启，因为要解析等待超时之后，才允许登陆机器。解决方法：启动DNS服务1.smitty named或startsrc -s named再次telnet登陆，登陆就正常了，xmanger图形界面也正常使用了.后记：该类故障不大，但是对于一个DBA来说，如果小型机工程师没有在现场（周末这类的），你有急需要登陆小机安装oracle或grid ，没有图形界面如何

摘录一篇晶晶小妹的关于检查点与rba的文章，写的很好。原文链接http://bbs.chinaunix.net/thread-1278164-1-1.html[@more@]**为什么要有检查点？被修改过的块，在oracle中都被统称为脏块.所有的脏块被一个链表串起来,称做检查点队列.在buffer cache中,每一个块都有一个buffer header 简称BH,在BH中有一个ckptq项,此项目中记录了指向检查点队列上一个块和下一个块的指针.如果某一个块不在检查点队列中,他的ckptq项为空.通过ckptq项oracle将所有的脏块串成了一个双向链表.这个双向链表就是检查点队列了.1,只有脏块才会在检查点队列中,非脏块

Redo Byte Address (RBA)来源http://www.ixora.com.au/notes/rba.htm[@more@]Recent entries in the redo thread of an Oracle instance are addressed using a 3-part redo byte address, or RBA. An RBA is comprised of the log file sequence number (4 bytes) the log file block number (4 bytes) the byte offset into the block at which the redo record starts (2 bytes) RBAs are not necessarily unique within their thread, because the log file sequence number may be reset to 1 in all threads if a database is opene

系统表空间恢复[@more@]Ø 系统表空间损坏或丢失 SQL> alter database open resetlogs;alter database open resetlogs*ERROR at line 1:ORA-01157: cannot identify/lock data file 1 - see DBWR trace fileORA-01110: data file 1: '/u01/oradata/retc/rwsw_system' SQL> recover database using backup controlfile;ORA-00283: recovery session canceled due to errorsORA-01110: data file 1: '/u01/oradata/retc/rwsw_system'ORA-01157: cannot identify/lock data file 1 - see DBWR trace fileORA-01110: data file 1:

数据文件恢复[@more@]Ø 数据文件rwsw_quest1损坏或丢失SQL> alter database open resetlogs;alter database open resetlogs*ERROR at line 1:ORA-01157: cannot identify/lock data file 11 - see DBWR trace fileORA-01110: data file 11: '/u01/oradata/retc/rwsw_quest1'SQL> recover database;ORA-00283: recovery session canceled due to errorsORA-01610: recovery using the BACKUP CONTROLFILE option must be doneSQL> recover database using backup controlfile until cancel;ORA-00283: recovery session

联机重做日志文件恢复[@more@]Ø 损坏状态为INACTIVE的联机日志文件SQL> select group#,thread#,sequence#,members,archived,status,first_change# from v$log order by group#;GROUP# THREAD# SEQUENCE# MEMBERS ARCHIV STATUS FIRST_CHANGE#---------- ---------- ---------- ---------- ------ -------------------------------- ------------- 1 1 9 2 YES INACTIVE 30536577211 2 1 8 2 YES INACTIVE 3053657

全库恢复到另外一台测试库，属于异机恢复[@more@]Ø 测试库创建PFILE参数文件INITSHESTATE.ORA*.aq_tm_processes=0*.compatible='9.2.0.0.0'*.db_block_size=8192*.db_cache_size=268435456*.db_name=shestate*.db_file_multiblock_read_count=16*.job_queue_processes=10*.open_cursors=300*.pga_aggregate_target=254803968*.processes=150*.session_max_open_files=20#*.sga_target=767557632*.sga_max_size=536870912*.large_pool_size=33554432*.shared_pool_size=262144000*.sort_area_size=524288*.undo_management='AUTO'*.

控制文件恢复[@more@]$ export ORACLE_SID=shestate$ rman target / nocatalogRecovery Manager: Release 9.2.0.5.0 - 64bit ProductionCopyright (c) 1995, 2002, Oracle Corporation. All rights reserved.connected to target database (not started)RMAN> set dbid=3563853082executing command: SET DBIDRMAN> startup nomount;Oracle instance startedTotal System Global Area 1411877936 bytesFixed Size 744496 bytesVariable Size 1358954496 bytesDatabase Buffers 50331648 bytesRedo Buffers 1847296 bytesRMAN> RU

搞懂介质恢复-使用备份的控制文恢复数据库[@more@]数据文件user01.dbf丢失，控制文件丢失--restore controlfile;--restore datafile 4;--目前数据库为mount状态：查看相关SCN:--备份控制文件记录的CNSQL> select checkpoint_change# from v$database;CHECKPOINT_CHANGE#------------------5277885--备份控制文件记录的SCNSQL> select file#,checkpoint_change# from v$datafile;FILE# CHECKPOINT_CHANGE#---------- ------------------1 52779302 52779303 52779304 52779305 52779306 52779307 52779308 5277930--当前数据库数据文

搞懂介质恢复-使用当前的控制文件恢复数据库[@more@]数据文件users01丢失1.首先是restore数据文件restore前：比较SCN控制文件记录的SCNSQL> col checkpoint_change# for 9999999999SQL> select file#,checkpoint_change# from v$datafile;FILE# CHECKPOINT_CHANGE#---------- ------------------1 52736332 52736333 52736334 52736335 52736336 52736337 52736338 5273633数据文件记录的SCNSQL> select file#,checkpoint_change# from v$datafile_header;FILE# CHECKPOINT_CHANGE#---------- ------------------1 52736332 5273

作者: Fenng | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明网址: http://www.dbanotes.net/database/rman_nocatalog_lost_controlfile_howto.html 解决过程[@more@]首先，用控制文件作数据库系统的全备份： C:WUTemp>rman target / Recovery Manager: Release 9.2.0.1.0 - Production. Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved. connected to target database: DEMO (DBID=3272375326) RMAN> run {2> allocate channel C1 type disk;3> backup full tag 'Ful

作者: Fenng | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明网址: http://www.dbanotes.net/database/rman_nocatalog_lost_controlfile_howto.html 情况描述客户报告数据库故障，新来的系统管理员误操作。删掉了一些文件。具体情况是：删掉了所有重要数据文件、所有控制文件。数据库原来是归档模式，用 RMAN (Recovery Manager) 备份数据，而 RMAN 使用控制文件。幸运的是，最后一次 RMAN full 备份是包括了控制文件在内。系统没有设定自动备份控制文件。现在状况是数据库无法启动。 不用说，客户的备份方案不够完善

有这样的一种需要恢复数据库场景：当前数据库有一份全备，归档，联机重做日志都没有损坏或丢失，但是控制文件意外的损坏了，而且更糟糕的是，居然没有备份的控制文件（当然， 这种情形很少见），这种情形下，只有重建控制文件，但是重建控制文件也是一件很棘手的事情，如果数据库有上百个数据文件，要写在控制文件里，不是件容易的是，这就要求数据库管理员对数据库结构相当熟悉。这也是说明了控制文件的重要性了。我这里的场景是使用alter database backup controlfile to trace得到重建控制文件的脚本，纯粹是为了今天要说的主题来的。在

在备份集无法restore的情况下，使用dbms_backup_restore包在nomount状态下restore数据文件，然后恢复数据库。[@more@][oracle@primary dbs]$ rman target /Recovery Manager: Release 10.2.0.5.0 - Production on Sun Dec 2 15:18:58 2012Copyright (c) 1982, 2007, Oracle. All rights reserved.connected to target database: dbwdn (not mounted)RMAN> run2> {3> allocate channel t1 device type disk;4> restore database from '0vnrrptr_1_1.bak';5> release channel t1;6> }using target database control file

copy datafile 与copy datafilecopy的区别：[@more@]RMAN> copy2> datafile '/u01/app/oracle/oradata/dbwdn/users01.dbf' to '/tmp/users01.dbf';Starting backup at 02-DEC-2012 13:57:54using channel ORA_DISK_1channel ORA_DISK_1: starting datafile copyinput datafile fno=00004 name=/u01/app/oracle/oradata/dbwdn/users01.dbfoutput filename=/tmp/users01.dbf tag=TAG20121202T135754 recid=12 stamp=800978275channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01Finished backup at 02-DEC-2012 13:5