Author: mac

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638    QQ号:47079569    邮箱：[email protected]       主要内容   应用于   产品: 10.1 至 12.1版的Oracle 数据库     要收集什么以及为什么？     SRDC 要收集分析ORA-08102所报告的块损坏所需的信息。   操作计划   确定受影响的索引 该错误以及ORA-08102 的追踪文件为受影响的索引提供了obj# (object_id) 。 SQL*Plus 会话收到该错误的例子：     SQL> DELETE dept WHERE deptno=10; DELETE dept WHERE deptno=10 * ERROR at line 1: ORA-08102:…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638    QQ号:47079569    邮箱：[email protected]   症状 1)从备份中恢复数据库，并进行不完全恢复 2) 用 resetlogs打开数据库。 3) 打开数据库后，会收到以下报错： ORA-00600 [kclchkblk_4] ORA-00600 [2662] 来自ALERT 的示例输出： Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_smon_7493.trc: ORA-600: internal error code, arguments: [kclchkblk_4], [1904], [18446744073431179384], [1904], [18446744073403569507], [], [], [] Starting background process QMNC QMNC started with pid=24, OS id=8329 Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_smon_7493.trc: ORA-600:…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638    QQ号:47079569    邮箱：[email protected]   症状 –问题陈述： 无法使用DBMS_FILE_TRANSFER复制ASM文件。 — 重现步骤： SQL> create directory backupto as ‘C:\Experteam\Backup\RMAN\Supp’; 新建的目录. SQL> create directory backupfrom as ‘+RECDISK/TOTALDB/BACKUPSET/2007_07_02’; 新建的目录. SQL> BEGIN 2 dbms_file_transfer.copy_file 3 ( 4 source_directory_object => ‘backupfrom’, 5 source_file_name => ‘nnndf0_BACKUP_TOTALDB_000_0702070200_0.548.62683’, 6 destination_directory_object => ‘backupto’, 7 destination_file_name => ‘nnndf0_BACKUP_TOTALDB_000_0702070200_0.548.62683’ 8 ); 9 END;…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638    QQ号:47079569    邮箱：[email protected]   症状 ASMCMD RM命令未能删除ASM上的EXPDP转储文件，报错ORA-15032 ORA-15173。 ASMCMD> rm RAMSESSYS_EXPORT_SCHEMA_01_174126_1.257.63370153 ORA-15032: 未执行所有的变更 ORA-15173: 条目 ‘RAMSESSYS_EXPORT_SCHEMA_01_174126_1.257.63370153’ 不在目录 ‘DUMPSET’中 原因 ASMCMD工具将文件名截断到48个字符，而实际上文件名更长。 下列查询表明，该文件名被截断： select f.file_number, a.name , (‘+’ || g.name||’.’||f.file_number||’.’||f. incarnation) asm_filename, f.type from v$asm_diskgroup g, v$asm_file f , v$asm_alias a where g.group_number=f.group_number and g.group_number=a.group_number and f.file_number=a.file_number order by f.file_number; FILE_NUMBER…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638    QQ号:47079569    邮箱：[email protected] 症状 无法MOUNT或删除磁盘组 SQL> ALTER DISKGROUP CIF_RECO_01 mount; ALTER DISKGROUP CIF_RECO_01 mount * ERROR at line 1: ORA-15032: not all alterations performed ORA-15063: diskgroup “CIF_RECO_01” lacks quorum of 1 PST disks; 0 found 主要问题是，需要删除该磁盘组，从而在另一个磁盘组中使用磁盘。 原因 删除磁盘组要求MOUNT磁盘组。如果磁盘组无法MOUNT，那你需要覆盖磁盘的第一个块，使之看起来不像个位于你想删除的磁盘组中的磁盘。有几种方法可以做到这一点。这些方法都很危险，因为如果你打出错误的设备名称，可能会毁掉运行中的磁盘组。 1. 你可以用’dd’ Unix 命令在块0磁盘头上写一个零块。 2. 你可以使用FORCE选项将该磁盘添加到新的磁盘组。 3. 你可以使用FOECE选项，以及旧磁盘中的所有磁盘来创建一个新的磁盘组。那么新的磁盘组可以MOUNT也可以删除。相比于选择2的唯一好处就是FOECE添加可以一次完成，这样新磁盘的添加可以在一段时间内完成，无需一直使用FOECE选项。 解决方案 下列步骤也是一种方法，可以实现这一目的。 1.…

在12.1中Oracle ASM提供了一个改善可用性和可靠度的的新特性 称作Scrubbing Disk Groups， Disk Scrubbing通过检查数据的逻辑讹误，从而能够在Normal 或者High Redundancy的disk group上修复它们。 Scrubbing 进程需要利用镜像盘来修复逻辑讹误。Disk Scrubbing可以与disk group rebalancing组合使用以减少I/O资源消耗。Disk Scrubbing对产品环境的I/O影响不大。 用户可以指定具体要Scrubbing的磁盘组，特定的磁盘，或者磁盘组内的某一个文件，具体要使用ALTER DISKGROUP命令。如下面的例子：     SQL> ALTER DISKGROUP data SCRUB POWER LOW; SQL> ALTER DISKGROUP data SCRUB FILE ‘+DATA/ORCL/ASKMACLEAN/example.266.806582193’ REPAIR POWER HIGH FORCE; SQL> ALTER DISKGROUP data SCRUB DISK DATA_0005 REPAIR POWER HIGH FORCE;     当执行如上SCRUB 时：   选项REPAIR指定自动修复磁盘讹误，如果未指定REPAIR，则SCRUB仅检查和报告指定目标的逻辑讹误。…

在Oracle 11g中 Data Guard的redo传输工作主要由以下3组后台进程实现： ARCi (FAL – archived redo shipping, ping, local only archivals) NSAi (async) 12.1 name: TTnn , NSSi (sync) –– live redo shipping   但从版本12c开始 使用TTnn  例如TT00进程来负责async 异步的redo传输。 另一个后台进程TMON来负责做Redo transport monitor。   SQL> select banner from v$version where rownum=1; BANNER ——————————————————————————– Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 – 64bit Production SQL>…

12c R1 中引入了SQL优化的新特性- Adaptive Execution Plans 自适应的执行计划，该特性让优化器optimizer 可以在运行时(runtime)自动适配一个性能不良的执行计划， 并避免在后续的仍选择该性能糟糕的执行计划。   SQL优化器将在运行时 最终确定其使用的执行计划， 这样可以检测到优化器一开始评估的执行计划可能不是最优的。这样执行计划就可以自动适配到实际的运行条件中。一个自适应的执行计划adaptive plan 是在优化器第一次硬解析得到执行计划后在运行时选择了与原计划有区别的子计划，选择子计划subplan的原因是优化器认为一开始的评估并不准确。   换大白话来说， 即便统计信息准确 优化器的评估也可能与实际有出入，但没法在执行前知道， 现在的办法是 先让优化器和平时一样给一个认为”最佳的”执行计划， 在执行过长中对某些数据源获得的结果集做buffer 来统计实际行数  然后和优化器评估的做比较，看是否准确，不准确则变化之后的可以改动的执行计划。   优化器optimizer 自适应执行计划是基于语句执行时的执行信息统计数据的，这些数据在执行时被收集。所有的自适应技术都可能执行一个不同于优化器最初硬解析获得的plan的计划。 这是12C中对查询处理引擎的重要提升， 优化器的判断将更注重了解过去的执行情况，即优化器有了 前事不忘后事之师的能力。   自适应执行计划主要有以下2个技术：   Dynamic Plans动态计划： 动态计划是指在语句执行期间在多个子计划之间选择；对于动态计划，优化器optimizer需要决定哪一个子计划subplans最终将包含在本次的动态计划中， 哪些执行统计信息需要收集以便选择子计划，以及做出选择需要机遇的阀值。 Reoptimization再次优化: 与Dynamic Plans不同的是，Reoptimization是在当前执行之后再次执行时改变执行计划。对于Reoptimization而言，优化器必须判断在原执行计划的哪一步收集哪些统计信息，以及reoptimization是否可行。     OPTIMIZER_ADAPTIVE_REPORTING_ONLY 参数控制 report-only模式的自适应优化。当该参数设置为TRUE，则自适应的优化器以report-only模式运行，仅收集自适应优化器所需要的信息，但是不采取改变执行计划的行动。   Dynamic Plans 动态执行计划仍是一个执行计划，只是它有着多个不同的内置计划选项。在第一次执行时， 在某个特定的子计划激活之前，优化器将作出最终的决定，选择哪一个选项被使用。优化器的选择基于它运行到这一个步骤的整个过程间观察到的数据。 动态计划是优化器最终启用的final plan不同于硬解析时获得的默认计划default plan， 由于final plan比default plan更了解实际情况，所以往往可以改善查询性能。…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638    QQ号:47079569    邮箱：[email protected]   ORACLE  TSPITR  是 Tablespace Point-in-Time Recovery的简写 在相同的服务器上 查询数据文件相关信息 SQL> select tablespace_name,file_id,file_name from dba_data_files order by tablespace_name;   TABLESPACE_NAME  FID FILE_NAME ————— —- ————————————————– EXAMPLE            5 /u01/app/oracle/oradata/dbdao01/example01.dbf SYSAUX                 2 /u01/app/oracle/oradata/dbdao01/sysaux01.dbf SYSTEM                1 /u01/app/oracle/oradata/dbdao01/system01.dbf UNDOTBS1          3 /u01/app/oracle/oradata/dbdao01/undotbs01.dbf USERS                   4 /u01/app/oracle/oradata/dbdao01/users01.dbf askmac.cn  …

在Oracle database 12c 中引入V$EVENT_NAME 视图新增字段DISPLAY_NAME，该字段用以更详细地解释对应的等待事件：   DISPLAY_NAME VARCHAR2(64) A clearer and more descriptive name for the wait event that appears in the NAME column. Names that appear in the DISPLAY_NAME column can change across Oracle Database releases, therefore customer scripts should not rely on names that appear in theDISPLAY_NAME column across releases.   可惜的是目前并非所有的event都有对应的DISPLAY_NAME，我们列出在12.1.0.1中现有的display name:   select name,display_name,wait_class from v$event_name…