Author: mac

我们在学习Oracle入门知识时都会介绍到ARCH归档进程，归档进程ARCH负责将在线重做日志归档，注意ARCH只会将日志文件中存在的重做内容复制到归档日志文件中，举例来说重做日志文件的大小是512MB，但当前写入的redo entry只占用10MB空间，此时由某些条件触发了日志切换，那么产生的归档文件的大小仍是10MB。 一直以来存在着这样一种误解：归档操作只会由ARCH进程负责完成。 实际上归档操作可能由多种进程完成，举例来说前台进程Fore ground process就可以完成归档操作，当在前台进程中执行alter system archive log current命令时实际执行归档操作的是前台进程(server process)，而非ARCH，这可能是大多数人料想之外的，口说无凭，我们具体验证一下: [oracle@rh2 ~]$ ps -ef|grep LOCAL=YES|grep G10R2 oracle 20790 20789 0 19:17 ? 00:00:00 oracleG10R2 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) SQL> set linesize 200 pagesize 1400; SQL> select le.leseq “Current log sequence No”, 2 100 * cp.cpodr_bno / le.lesiz “Percent Full”, 3 (cpodr_bno – 1) * 512 “bytes used…

  如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected] 如何保证索引删除和重建 目的 ——- 为确保 ORA-8102问题得到恰当解决。 范围和应用 ——————- 在8.0.6 及更高的版本中是固定的，请参考 Bug:536567 相关文件 —————– NOTE:20755.1OERR: ORA 8102 “index key not found, obj# %s, dba %s (%s)” 在这方面重建索引遇到问题时，会出现诱惑, 特别是当基表有很多行数时。让我们一起回顾这些命令。 1) ALTER INDEX … REBUILD; 该索引将从自身从索引中的损坏信息中重建，于是，损坏就保留了。 2) CREATE INDEX …. 该索引可以使用现有索引的快速全扫描建立，这可能会再次导致损坏发生，为成功解决该问题，该索引和任何有问题的带有很多列的索引在该索引重建之前必须丢弃，这可确保在表中驱除数据的索引的创建。所以，换句话说，如果损坏索引被丢弃，例如，由 (COL A, COl B)组成的索引，但是列组合存在于其他索引中，比如会使用 (COL B, COL A) ，损坏可能会再次蔓延。 要诊断是否遇到这个问题，从user_dump_dest目录ORA-8102跟踪文件中，一个典型的调用堆栈是：…

事实: Oracle服务器 – 企业版 症状: alert.log中出现间歇性消息 症状: 损坏块相对数据库管理员: … 症状: 用户缓冲块读取时发现损坏块 症状:在直接路径 I/O中出现假的损坏块信息 症状: 重读 rdba 发现有效数据 原因: Bug:2354965: 用户缓冲器在Alert.log读取时发现间歇性损坏块 在alert.log中出现损坏块的间歇性信息，如下: 损坏块相对数据库管理员: 0x8ec05e93 file=571. blocknum=24211. 用户缓冲器读取时发现损坏块 坏块中数据 – type:6. format:2. rdba:0x8ec05e93 上次更改 scn:0x0078.ec15811c seq:0x1 flg:0x04 尾部值的一致性 0xd6f70601 块头值的检查: 0xa093, calculated check value: 0x57eb spare1:0x0, spare2:0x0, spare2:0x0 重读 rdba=8ec05e93 file=571. blocknum=24211. 找到有效数据 修复: 要么: 对Bug:2354965使用补丁 要么: 使用以下解决方法:1. Set …

  如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected] 产品: Oracle Server – 企业版 9.2.0.1.0 平台: Solaris 操作系统(SPARC) (64-bit) 症状 ~~~~~~~~~~ ORA-07445: 出现异常: 核心转储 [FFFFFFFF7C300AA4] [SIGBUS] [对象特定硬件错误] [0xFFFFFFFF7A0A4000] [] [] *** 损坏块相对数据块号: 0x01c636a2 (file 7, block 407202) buffer cache 读取中发现坏头 坏块中数据- type: 6 format: 2 rdba: 0x01c636a4 上次更改 scn: 0x0000.002c370f seq: 0x1 flg: 0x06 尾值的一致性: 0x370f0601…

ASMLIB是一种基于Linux module，专门为Oracle Automatic Storage Management特性设计的内核支持库(kernel support library)。 长久以来我们对ASMLIB的认识并不全面，这里我们来具体了解一下使用ASMLIB的优缺点。 理论上我们可以从ASMLIB API中得到的以下益处: 总是使用direct,async IO 解决了永久性设备名的问题，即便在重启后设备名已经改变的情况下 解决了文件权限、拥有者的问题 减少了I/O期间从用户模式到内核模式的上下文切换，从而可能降低cpu使用率 减少了文件句柄的使用量 ASMLIB API提供了传递如I/O优先级等元信息到存储设备的可能 虽然从理论上我们可以从ASMLIB中得到性能收益，但实践过程中这种优势是几乎可以忽略的，没有任何性能报告显示ASMLIB对比Linux上原生态的udev设备管理服务有任何性能上的优势。在Oracle官方论坛上有一篇<ASMLib and Linux block devices>讨论ASMLIB性能收益的帖子，你可以从中看到”asmlib wouldn’t necessarily give you much of an io performance benefit, it’s mainly for ease of management as it will find/discover the right devices for you, the io effect of asmlib is large…

11.2.0.2的grid infrastructure中crsctl stat res 命令不再显示如ora.cssd、ora.ctssd、ora.diskmon等基础资源的信息，如果用户想要了解这些resource状态需要加上-init选项: [grid@rh2 ~]$ crsctl query crs activeversion Oracle Clusterware active version on the cluster is [11.2.0.2.0] [grid@rh2 ~]$ crsctl stat res -t ——————————————————————————– NAME TARGET STATE SERVER STATE_DETAILS ——————————————————————————– Local Resources ——————————————————————————– ora.DATA.dg ONLINE ONLINE rh2 ora.LISTENER.lsnr OFFLINE OFFLINE rh2 ora.asm ONLINE ONLINE rh2 ora.gsd OFFLINE OFFLINE rh2 ora.net1.network ONLINE ONLINE…

我们在诊断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…

事情是这样的，客户有一套核心的10g业务数据库，需要针对个别大表删除2年前的归档数据，这些表都是普通的堆表(heap table)，没有使用分区或其他技术。因为考虑到不能影响在线业务，所以不能使用insert append/rename的方式来加速删除，只能老老实实地在匿名PL/SQL块里通过rowid批量删除数据，虽然慢一些但还是能接受的,具体的PL/SQL块如下: DECLARE CURSOR table_name_cur IS SELECT /*+ FULL(a) */ a.rowid from table_name a where time_column<required_date table_name_rec table_name_cur%ROWTYPE; row_number number; BEGIN row_number :=0; OPEN table_name_cur; LOOP FETCH table_name_cur INTO table_name_rec; IF table_name_cur%NOTFOUND THEN commit; EXIT; END IF; delete from table_name WHERE rowid = table_name_rec.rowid; row_number := row_number + 1; if (mod (row_number,1000) =0) then…

我们在大的事务失败时往往面临长时间的回滚，在回滚期间表会被加以TM-3 SX sub-exclusive锁，此时一般我们是无法针对表实施DDL操作的。长时间的大事务回滚可能耗尽我们的耐心，不过我们还是有办法预估何时回滚能够完成的，参考中的脚本<Script:when transaction will finish rollback>中的脚本，注意该脚本需要访问x$ktuxe内部视图，所以需要以sysdba身份方能执行。 SQL> select * from v$lock where type in (‘TM’,’TX’); ADDR KADDR SID TY ID1 ID2 LMODE REQUEST CTIME BLOCK ——– ——– ———- — ———- ———- ———- ———- ———- ———- 0ED0F30C 0ED0F33C 9 TM 13865 0 3 0 3757 0 2C3975FC 2C39763C 9 TX 65557 677 6 0 3757…

我们在学习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…