Author: mac

vs. 存储功能备份 备份的全面损坏的风险 备份的性能与负荷 管理性 破损块对策 ASMrebalance的影响 restore& recovery的灵活性 D2D（Storage Backup） vs. Oracle Recovery Manager D2D RMAN 备份的全部损坏风险 × 有全部损坏风险 ◎ 可以通过高速增量备份回避 备份的 性能与负荷 消費资源 ◎ 仅限存储的资源 △ 使用服务器的资源 总I/O量 ○ 仅限sector单位中的差分 ○ 仅限块单位中的差分 保持数据总量 △ 与正式volume同等的尺寸 ○ 可以压缩、减少 Redo生成量 × 备份中増加 ◎ 与一般的情况相同 管理性 × 人工管理比较麻烦 ○ 自动管理 泛用性 △ 依赖于存储供应商 ○ 从H/W结构中独立出来 破损块对策…

Oracle ASM的基本思想 通过应用ASM使得设计/使用简便化 ASM设计指针 ASM的Rebalancing 与 stripe High Redundancy的优点 vs. Sympro /阶层化存储   传统的存储物理设计手法 部分最优化 对每个访问类型都分配磁盘配置数据 –随机访问（重视待机时间最小化的IOPS） Seek等待时间 + 回转等待时间 > 读出时间 –sequential访问（重视完全灵活使用传送带宽的吞吐量） seek等待时间 + 回转等待时间 < 读出时间   Hard Disk Drive技术演进 随机访问的并列化时sequential访问也高速化   1.提高Disk回转速度 缩短同样的数据的读出时间 变更sector的配置，缩小搜索范围 2.Disk外周的sector的高密度化 周边seek增多，头的移动距离锁定，随机访问高速化 3.Disk的低价化 通过将多个disk捆在一起，可以保证I/O性能   存储物理设计的変化 从部分最优化到整体最优化 通过访问类型来分离的需求减少 –灵活利用所有disk，最大化发挥I/O性能=》采用 S. A. M. E     Oracle ASM的基本思想 Stripe…

用户的SIEBEL RAC系统中配置了OGG 11.1.1.1.2 ，在最近发现备份脚本未正常将归档日志备份后删除掉，示例日志如下：   iece handle=al_18090002_1_848331814 tag=TAG20140523T154330 comment=API Version 2.0,MMS Version 5.0.0.0 channel ch00: backup set complete, elapsed time: 00:01:35 channel ch00: deleting archived log(s) RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process archived log file name=/ora/archivelog/2014_05_21/o1_mf_2_171530_1cccD0E1h_.arc thread=2 sequence=171530 RMAN-08137: WARNING: archived log not deleted, needed for standby or…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   问题描述 ——————- 执行SQL语句时，会得到错误： ORA-1115：IO错误读取块，来自文件XX（块#XXX） 上述错误可能伴随下列错误中的一个或多个： –   ORA-604：在递归SQL 级时出错   ORA-1110：数据文件N：”   ORA-27041：无法打开文件   RMS％-E-ACC，ACP文件访问失败 通过不同类型的连接，执行相同的语句时可能不会出现该问题。 例如，执行SQL*net出错，但若是相同的语句从数据库的本地连接发出就不会出错 解决方案说明 ——————– 如果没有其他错误与ORA-1115一起出现，则表明是硬件问题（如ORA-27091：skgfqio：无法排队I / O），那么问题是几乎可以肯定是由于缺乏VMS配额FILLM和/或BYTLM 如果语句未能连接到SQL * Net连接，请检查Note:68663.1，增加FILLM和BYTLM 如果语句未能连接到在本地（BEQ）连接，请检查Note:70671.1，增加FILLM和BYTLM 解释说明 ———– 你可能会遇到这个错误，如果： o    这个新语句涉及大多数数据文件 o    你最近增加了一个新的数据文件到你的数据库 这个问题中有两个可能的的配额 FILLM ===== 给定的过程必须具有足够的FILLM配额，以便能够打开所有受失败语句影响的数据库文件。 如果当前FILLM过程的配额接近给定数据库的数据文件数量，增加FILLM配额，使得它超出文件总数至少100（允许其他非Oracle文件以及未来增长）。 BYTLM ===== 每个打开的文件需要大约200字节BYTLM配额。 然而，BYTLM对于Oracle系统操作比处理打开文件重要得多。 目前的建议是将BYTLM配额至少设置为750000。 以往的文档: ============== 在Oracle8.0.3版本中（具有快速I / O），有个问题（根据SYSGEN参数FAST_PATH的值），即每打开一个数据库文件需要1024字节BYTLM配额。 （参考bug:706775）

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]     问题描述: ==================== 当Oracle由于I / O错误无法读取开放数据文件， 就会出现ORA-0111：  ORA-01115：“文件％s（块＃％S）中的IO错误读取块”  原因：该文件所在的设备可能是离线  动作：恢复对设备的访问 ORA-01115错误之后通常还会出现： – 一个ORA-01110错误 – 操作系统级的Oracle错误信息，如ORA-0737X – 一个操作系统错误（例如，错误＃5在UNIX中） 解决方案说明: ===================== 由于大多数ORA-01115 是由硬件问题造成的，解决方案首先是分解它们，然后如果有必要，在数据库级解决问题。 进行硬件检查是必不可少的。如果硬件问题不解决，试图在数据库级解决问题也没用。运行操作系统级的实用程序和诊断工具来检测磁盘，控制器和I/ O子系统是否正常运行。要特别注意ORA-01115所引用的的数据文件所在磁盘。您的系统管理员应该能够帮助您完成这一任务。 如果可行的话，这些诊断应与此处建议的步骤同时进行，或紧随其后尽快完成。 确定ORA-01115的确切原因也很重要。方法取决于你是否知道问题的原因。 I.原因尚不清楚时解决问题的步骤 ————————————————– ———-   1.尝试评估问题的原因和程度。       检查alert.log文件中的实例，扫描最后几天的条目寻找ORA-01115的其他实例。如果你找到实例，分析一下几种情况：         A）他们是否在不同的磁盘上引用文件？                 如果是，很可能是控制器有问题。                 请继续阅读下面的方案II.A。         B）他们是否在同一个磁盘引用不同的文件？                 如果是，则很可能是该磁盘有问题。                     请继续阅读下面的方案II.B。…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   本说明讲的是在数据库的块包指示该块损坏时对损坏块的处理，是对Note:28814.1文章的延伸 (主要针对ORA-1578 错误)。   如果只发生块内部损坏，这里的细节将不再适用(例如: ORA-600 或其它errors)，在这种情况下，从Oracle8i起有可能使用DBMS_REPAIR将问题块标记为软损坏，这样在访问时，就会发出ORA-1578信号。 DBMS_REPAIR.CHECK_OBJECT / FIX_CORRUPT_BLOCKS用法的更多详情请看10.2   阅读本说明之前，请阅读 Note:28814.1。   该方法只适用于堆组织表，索引组织表 (IOT) 的方法请参考Note 794772.1 – 事件“在索引扫描时检查和跳过损坏块” 引言 ~~~~~~~~~~~~ 这篇短文解释了如何跳过对象上的损坏块，使用SKIP_CORRUPT表标志（从Oracle8i中起存在）或特殊的Oracle事件编号10231（从Oracle版本7到更包容性的8.1上可实现）。 这里的信息解释了如何使用这些选项。 处理之前，应该: a)  确认块损坏在 USER t表上(即：不在数据字典表上) b)  已联系Oracle 支持服务，被建议使用事件10231 或SKIP_CORRUPT 标志 c)  已确定如何重建表格，例如：输出、使用磁盘空间等等。 d)  已计划停机时间以尝试进行补救操作，或者已在别处保存了一个问题数据库的副本，以便在在副本上进行数据提取。 e)  数据库备份 f)  使用SQL重建问题表，它的索引、约束、触发器等。     该SQL 应该包含相关的存储子句。

  如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]     目的 本文献提供了DBMS_REPAIR（在 Oracle 8i引入）的例子。 Oracle提供了多种不同的检测和修正数据块损坏的方法，DBMS_REPAIR就是其中之一。 警告: 涉及数据丢失的任何损坏，需要分析、了解这些数据是如何融入整个数据库系统，根据维修的性质，可能会丢失数据，导致逻辑的不一致，所以，需要仔细权衡使用DBMS_REPAIR.的利弊。 范围和应用 本文仅仅旨在帮助有经验的数据库管理员与Oracle全球支持分析师的工作，本文不包含有关DBMS_REPAIR包的一般信息，相反，它旨在提供可以由用户（借助Oracle技术支持分析师的协助）进行定制的示例代码来解决数据库损坏问题。应阅读Oracle数据库管理员指南的“检测并修复数据块损坏”一章，在开始之前进行风险评估分析。 相关文献 Oracle 数据库管理员指南， DBMS_REPAIR章节 引言 ============= 注释: DBMS_REPAIR 包仅用于同处理层和数据层的损坏（软件损坏快）一起工作。发生物理损坏的块被标记（例如：断裂块），因为该块被写入高速缓存缓冲区，DBMS_REPAIR忽略了所有标记为损坏的块。 DBMS_REPAIR的最初版本的唯一的块修复是 *** 标记块软件损坏 ***. 使用包之前，应进行损坏文件的备份。 数据库摘要 =============== 损坏的块存在于表T1中 SQL> desc t1 Name Null? Type —————————————– ——– —————————- COL1 NOT NULL NUMBER(38) COL2 CHAR(512) SQL> 分析表 t1 验证结构;…

为什么Oracle在有FREE空闲物理内存情况下仍使用SWAP交换空间换页？   oracle仅仅做为操作系统上的一个普通用户要求操作系统给其分配资源而已，其中包括内存资源，在许多unix/linux上使用shmget()函数调用申请内存， 对于分配到的内存 如果没有特殊配置的话，Oracle是不计较Unix/linux给它的到底是什么内存的，可能是可用的物理内存也可能是SWAP交换空间。而且在Oracle使用内存的过程中，也可能被操作系统换页到SWAP上。除非使用了LOCK_SGA、HUGE PAGE、PIN SHM等特性外，否则操作系统并不保证给Oracle的内存一定在物理内存里。   另外对于Unix/Linux换页的原理而言， 其仅仅是说在物理内存有压力时会更多考虑换页，但这不是说有物理内存就不换页，这是2个概念。所以你还是能看到系统有很多剩余物理内存，但却在使用一定量换页空间的情况，这并不奇怪。   对于十分纠结使用换页空间的环境，完全可以考虑使用上述LOCK_SGA、HUGE PAGE、PIN SHM等特性让Oracle尽量不被换页。这也是这些特性被设计出来的初衷。

#揭秘ORACLE#ORACLE目前的管理层架构，直接report给拉里的9人，总员工数大约12万。马克赫德负责全球范围的销售、咨询、市场和support，间接管理大约7万名员工。但是研发这条线不在马克赫德这里（可能是万幸），Thomas Kurian产品研发执行VP，这条线包括数据库中间件、应用研发等，间接管理近3万名员工  

在有充分审计Audit   SQL的情况下，定位某条DROp/Truncate DDl还是比较容易的。   问题是 没有任何SQL审计时呢？   首先需要 明确的是 对于 关键的产品数据库系统而言 有效的审计非常重要，不能将以下的方法当做审计选项来用。 其次对于重要的环境和重要的对象， 一般推荐创建一个DDL Trigger 让直接运行的DDL报错，而需要先将对应的DDL Disable之后才能成功 执行DDL， 这样可以降低表/索引因为人为失误导致的误操作。   最简单的仍是通过 dba_objects 定位其最后的DDL时间，虽然这个LAST_DDL_TIME 未必是真实的案发时间了， 但如何与应用程序报错结合起来 还是能大致了解问题发生的时间段的， 而这个时间段 对于问题追查至关重要。 此外对于DROP命令而言显然弄不到这个LAST_DDL_TIME。   接着可以通过ASH 视图 DBA_HIST_ACTIVE_SESS_HISTORY和 V$ACTIVE_SESSION_HISTORY来定位一些DDL语句， 由于ASH默认是1秒采样一次，所以如果遇到了一些例如RAC 中truncate/drop 常见的 DFS Lock Handle、Enqueue Lock等等待，那么一般ASH都能捕捉到这个DDL，当然这也看运气，毕竟ASH不是审计功能。   SQL_OPCODE    12 为DROP TABLE  10为 DROP INDEX、85为TRUNCATE TABLE、86为TRUNCATE CLUSTER select USER_ID,…