作者: Maclean Liu, post on June 20th, 2011 Below is a shell script which backup dmpfile to ASM storage everyday:
#!/bin/bash #asmcmd mkdir DATA/ASM_DATAPUMP_BACKUP #create directory ASM_DATAPUMP_BACKUP as ‘+DATA/ASM_DATAPUMP_BACKUP’; #grant read,write on directory ASM_DATAPUMP_BACKUP to system; #create directory LOGDIR as ‘/s01/logdir’; #grant read,write on directory LOGDIR to system; #create directory DMPBACKUP as ‘/s01/dmpbackup’; #grant read,write on directory DMPBACKUP to system; export ORACLE_HOME=/s01/oracle/product/11.2.0/dbhome_1; export . . . → Read More: Backup Script:Expdp Schema to ASM Storage
作者: Maclean Liu, post on May 27th, 2011 我们在诊断Oracle backup restore问题时总是希望能获得足够的诊断信息，一般来说RDA会是一个最好的诊断信息收集工具，但是有时候客户会很反感使用RDA(不信任感)，这里我们提供一段专门用来收集oracle备份恢复信息的脚本。
运行以下脚本需要设置合理的”ORACLE_HOME、ORACLE_SID”环境变量，并设置NLS_DATE_FORMAT环境变量，如
NLS_DATE_FORMAT=”DD-MON-RRRR HH24:MI:SS” export NLS_DATE_FORMAT
以”rman target /”登陆并运行:
spool log to rman_report.log set echo on show all; report schema; list incarnation; list backup summary; list backup; list copy; report need backup; report obsolete; restore database preview; spool log off
以下脚本在sqlplus中以sysdba身份执行，执行要求数据库至少处于mounted已加载状态下；注意该原始脚本是只读readonly的，它仅仅是读取数据字典，不会造成危害，当然请确保你的脚本来源!!
spool results01.txt set echo on feedback on time on timing on pagesize . . . → Read More: Script:收集Oracle备份恢复信息
作者: Maclean Liu, post on May 23rd, 2011 我们在学习Oracle的过程中，或多或少会存在个人对概念的理解错误、误解或者根本是教材编写存在不严谨的地方，这样或以讹传讹或三人言虎，导致在Oracle圈子存在着一些古老相传的迷信(superstition)，因为这些迷信已经深入人心了，所以我们几乎很难纠正过来；这其实很有意思，IT作为一个高科技的领域也会出现迷信，说明我们在IT技术的”教学”和”思考”上存在问题，这一点值得深思。
这里我列出几个最为常见的迷信，算作抛砖引玉:
1.几乎所有的Oracle入门教程都会在介绍Large pool的时候这样描述:”RMAN 备份使用large pool作为磁盘I/O缓冲区，配置Large pool有助于提高RMAN备份性能”
Truth：除非你启用了slaves IO，否则rman并不使用large pool
RMAN I/O可以分成三种模式:
Mode Disk tape Asynchronous I/O 绝大多数操作系统支持AIO，默认disk_asynch_io为TRUE，即默认启用磁盘异步IO。如果磁盘设备不支持AIO，那么会使用synchronous I/O。磁盘异步模式下RMAN I/O缓冲区域从PGA中分配，相关IO性能信息存放在V$backup_async_io视图中 磁带设备本身不支持AIO(tape I/O is always synchronous)，虽然默认tape_asynch_io为TRUE，但磁带设备只能通过IO slaves模拟异步IO，所以启用磁带AIO需要另外设置backup_tape_io_slaves=TRUE。此模式下RMAN I/O缓冲区从shared pool或者large pool中分配，相关IO性能信息存放在V$backup_async_io视图中 Synchronous I/O 若disk_asynch_io设置为false，或操作系统不支持异步IO，且dbwr_io_slaves=0时启用Synchronous I/O。此时RMAN I/O缓冲区从PGA中分配，相关IO性能信息存放在V$backup_sync_io视图中 默认backup_tape_io_slaves为false，即磁带设备默认不启用AIO而使用Synchronous I/O。此时RMAN I/O缓冲区从PGA中分配，相关性能信息存放在V$backup_sync_io视图中 Slaves I/O 启用disk slaves I/O，要求设置disk_asynch_io=false且dbwr_io_slaves>0。此模式下RMAN I/O缓冲区从shared pool或者large pool中分配，相关IO性能信息存放在V$backup_async_io视图中 设置tape_asynch_io=true且backup_tape_io_slaves=true时启用，磁带的AIO模式其实就是使用slaves Io模拟获得的。所以此模式下的一切和tape AIO完全一样
我们在使用RMAN备份数据库时无论是磁盘备份还是磁带备份总是优先期望使用AIO异步IO特性(tape aio比较特殊，见上表)，使用AIO的前提是设置合理的初始化参数以及操作系统支持AIO，如果我们使用的操作系统不支持AIO那么我们将不得不使用Synchronous IO同步IO。这并不是世界末日，因为Oracle提供了IO从属进程(slaves IO)来模拟AIO，当然这是退而求其次的。为了启用slaves IO，我们需要手动设置backup_tape_io_slaves或dbwr_io_slaves参数来启用IO从属特性，当使用磁带备份时设置backup_tape_io_slaves(此时tape_asynch_io应当为true)为true，当使用磁盘设备时设置dbwr_io_slaves(此时disk_asynch_io应当为false)为非零值。在启用slaves IO的前提下RMAN才会从Large pool当中分配内存并加以利用，如果没有配置large . . . → Read More: Does Rman Backup benefit from Large Pool?
作者: Maclean Liu, post on May 23rd, 2011 近日客户报多套10g的数据库在使用NBU磁带备份时出现RMAN FULL BACKUP十分缓慢的问题，这些数据库中最大一个的达到2.61T，该数据库在一个月前地全库0级备份耗时在3-4个小时，而在最近猛涨到17个小时。客户之前已经向Symantec提交了服务请求，但暂时没有得到结论。希望我们从Oracle角度分析该备份速度变慢问题。
我们首先分析了备份信息的动态视图V$rman_backup_job_details:
OUTPUT_DEVICE INPUT_TYPE ELAPSED_SECONDS INPUT_BYTES_DISPLAY INPUT_BYTES_PER_SEC OUTPUT_BYTES_PER_SEC 17 SBT_TAPE DB INCR 62078 2.61T 44.08M 18.10M
以上可以确认在对2.61T大小的数据库执行全库磁带备份时耗费了62078s，这里还显示了backup时每秒的读取IO为44M，每秒的写出IO为18M；这里不能因为简单的output io per second<input io per second，而断论写出能力存在瓶颈；备份时对数据文件的读取和写出backup piece到备份介质上的操作是一个整体，CPU、Input IO、Output IO任何一环都可能成为备份的瓶颈；譬如因为对数据文件的读取IO存在瓶颈，那么相应的写出IO也会慢下来；又譬如当RMAN与备份服务器之间的IO带宽存在瓶颈，那么相应的读取IO也会不得不慢下来。具体是哪一个环节出现了问题，我们需要求助于其他的RMAN动态性能视图，如:
V$BACKUP_SYNC_IO Displays rows when the I/O is synchronous to the process (or thread on some platforms) performing the backup.
V$BACKUP_ASYNC_IO Displays rows when the I/O is asynchronous . . . → Read More: Oracle备份恢复:Rman Backup缓慢问题一例
作者: Maclean Liu, post on May 10th, 2011 几天前被问到关于rman catalog兼容性的问题，catalog所在数据库版本与目标数据库版本不同会有影响吗？在我概念当中catalog所在数据库的版本并不会影响rman catalog的使用，但catalog schema的版本却有着明确要求，至于具体的兼容关系就不清楚了。
查了下MOS找到文档<RMAN Compatibility Matrix>,这个文档解释地比较清楚，存在3个基本的原则：
RMAN可执行文件的版本需要和target database目标数据库的版本一致(弱一致要求)，具体的合法组合如下面列出的表格 RMAN catalog schema版本必须大于等于RMAN可执行文件(强一致要求) RMAN catalog对target database目标数据库向后兼容，即支持早期版本的目标数据库
具体的可用版本组合:
Target/Auxiliary Database RMAN Executable Catalog Database Catalog Schema 8.1.7.4 8.1.7.4 >=8.1.7 8.1.7.4 8.1.7.4 8.1.7.4 >=8.1.7 >=9.0.1.4 9.0.1 9.0.1 >=8.1.7 >= RMAN executable 9.2.0 >=9.0.1.3 and <= Target database >=8.1.7 >= RMAN executable 10.1.0 >=9.0.1.3 and <= Target database >=9.0.1 . . . → Read More: 了解rman catalog的兼容性
作者: Maclean Liu, post on April 27th, 2011 一套10.2.0.4的单节点数据库在恢复数据文件时出现了ORA-00600: internal error code, arguments: [2608], [1], [0], [690423], [0], [690425], [], []内部错误，其日志如下:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options ORACLE_HOME = /s01/db_1 System name: Linux Node name: rh2.oracle.com Release: 2.6.18-194.el5 Version: #1 SMP Mon Mar 29 22:10:29 EDT 2010 Machine: . . . → Read More: Oracle内部错误:ORA-00600[2608]一例
作者: Maclean Liu, post on April 27th, 2011 ORA-01189错误常见于使用Create Controlfile命令时发现OFFLINE的数据文件或者备份文件生成于上一次的RESETLOGS之前，一般来说如果是在RESETLOGS前offline的数据文件，可以在CREATE CONTROLFILE命令中省略该offline datafile，在打开数据库后使用rename file命令修复其丢失的数据文件名，之后再将数据文件online；若不是offline datafile所造成的ORA-01189错误，就必须要找出与其他数据文件版本一致的数据文件或其备份才能解决该问题。
设想存在这样一个场景：数据库处于非归档无备份的状态，在周日使用shutdown immediate命令干净地关闭了数据库,到周一发现因为磁盘故障丢失了所有的控制文件，不得不使用Create Controlfile RESETLOGS重建控制文件，而在重建过程中又漏输了某条数据文件的记录，之后又使用alter database open resetlogs重置日志文件并打开数据库，此时发现丢失了一个数据文件，尝试使用针对offline datafile的处理方法将丢失的数据文件重命名(rename)，并尝试online该数据文件，毫无疑问我们会遇到ORA-01190 “control file or data file %s is from before the last RESETLOGS”错误，这时虽然我们手上有该”干净”的数据文件，却也没有办法使之online了。
这里我介绍一种使用bbed修改数据文件头的方法来解决该ORA-01189错误:
[oracle@rh2 controlfile]$ oerr ora 1189 01189, 00000, “file is from a different RESETLOGS than previous files” // *Cause: In a CREATE CONTROLFILE command either this file or all . . . → Read More: 使用bbed解决ORA-01189错误
作者: Maclean Liu, post on April 1st, 2011 exp导出文件大到文件系统放不下怎么办？
在Unix上一种行之有效的解决方法是创建一个命名管道，因为exp的导出dumpfile的内容是顺序的，可以将其内容重定向到管道并对该管道实施压缩操作，从而实现其直接的导出文件就是压缩过的。下面我们举出一个使用该中管道压缩的例子:
[oracle@vrh1 exp]$ exp system/oracle file=maclean.dmp tables=maclean.tv Export: Release 10.2.0.4.0 – Production on Fri Apr 1 17:03:09 2011 Copyright (c) 1982, 2007, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – Production With the Partitioning, Real Application Clusters, OLAP, Data Mining and Real Application Testing options Export done in . . . → Read More: 在Unix上使用管道压缩exp导出文件
|
|
最新评论