Author: mac

  • ORA-01555的主要发生原因以及应对方法

    本文地址: https://www.askmac.cn/archives/ora-01555.html ‎ 如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 : 13764045638 QQ号:47079569 邮箱:[email protected]   说明ORA-1555的主要发生原因以及应对方法。 [错误信息]   ORA‐01555 snapshot太旧了:回滚段编号string、名字 “string”太小   ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐   原因:一致读入中所需要的回滚记录被其他用户覆盖了 。   对应方法:使用自动UNDO管理模式时,请增加UNDO_RETENTION的设定值。不使用时,请使用更大的回滚段。         [技术说明]   ‐ 错误内容的解读以及发生错误时的对应方法   错误内存因为oracle读取一致性所需要的Before-image被覆盖了等等理由没有获得成功,就会作为错误输出。回滚段(后文中是RBS)是由很多的UNDO块变成的,Before-image被储存在UNDO块上。   一般而言,错误原因是以下两点。   RBS的数量因为尺寸不够,需要读取一致性的Before-image就被覆盖了   发生ORA‐1555 的SQL执行了较长时间(cursor的话,从启动后经过了较长时间)   ORA‐1555发生时,首先想到的对应方法是重新执行ORA-1555所发生的处理。大部分情况,通过重新执行,可以回避ORA-1555的错误。   但是,如果是使用只读事务,发生块故障,media故障等即使重新执行也会发生ORA-1555所以需要终止那个事务,修复故障等。   重新执行也会反复发生ORA-1555的案例中,请以这次的文章中所展示的基本的对策、详细的原因以及解决方法为参考,去除引发ORA-1555的原因。   抑制ORA‐1555发生的对应方法,如下所示。   Oracle8i 以前,UNDO_MANAGEMENT=MANUAL 的情况   增加RBS的数量、尺寸…

  • Oracle shared pool共享池详解

    本文永久地址:https://www.askmac.cn/archives/oracle-shared-pool%e5%85%b1%e4%ba%ab%e6%b1%a0%e8%af%a6%e8%a7%a3.html 理解shared pool共享池 子池分割以及子heap分割 共享池可以通过以下两个角度来分割。 1.根据CPU以及共享池尺寸来分割子池(自动手动均可) ⇒ 因为共享池latch(每个池中各有一个)的竞争分散 CPU 数、共享池的共享分割 2.根据持续时间来对子heap进行分割(仅限自动) ⇒ 通过使得持续时间较长的chunk一直存在,就可以防止碎片化 根据内存的持续时间来分割共享池   根据持续时间不同导致所储存的信息不同   子池的隐藏FREE区域(通称) 启动数据库之后会存在一个名为隐藏FREE(SubPool#0)的空白区域(Reserved Granule)。另外,在各个SubPool中也会分配一定的FREE区域。用V$SGASTAT观察到的FREE是包含SubPool#0的空白区域的总计。 SubPool#0的区域不会发生碎片化。 由于这些机制,指定的子池从隐藏FREE中获得区域的话,指定的子池就会无端扩张,产生尺寸偏差,导致发生ORA-4031。   共享池的FREE内存是指什么(v$sgastat.free memory) 隐藏FREE(Reserved Granule) 持续使用的话,慢慢地就会被分割到数个SubHeap中,消失的区域 Reserved FREE 通过设定shared_pool_reserved_size预约区域(默认是共享池的5%) 可以确保4400byte以上的chunk FREE chunk Free list中被连接的空白chunk,如果是区域的要求,无论何时都可以使用,但是,需要确保区域是连续区域。不足4400byte的chunk就会被确保下来   刷新LRU列表的机制   要求共享池的空白区域~ORA-4031的流程   子池、子heap之间的空白区域不是相通的 即使指定的SubHeap中需要空白区域,但也无法从其他的子池的内存或者其他subheap中获得。Free list不同的subheap来管理的。 刷新LRU列表,已经制成的空白内存就会分别返回各自的subheaplist。 为了制作(1.2)的空白,需要刷新LRU,如果找到了LRU中可以解压的chunk的话,就会激情那个chunk返回到free list中。     共享池的free内存候补 RECREATABLE chunk –使用LRU列表中被关联的chunk,当free内存不足时,无法进行pin,就会依次解压使用频率较低的chunk,返回free list。 –Free list存在于每个subheap中,因为并不会返回隐藏free,所以只能在同样的subheap中重复利用。 –flush…

  • 深入了解Oracle Patch Set Release PSR 11.2.0.4

    Oracle Database的补丁种类 Patch Set Release 是包含故障修复以及功能扩张的oracle database中重要的补丁 PSR 的安装中需要使用 Oracle Universal Installer (OUI) 所有的补丁中最长的发布周期 Oracle Database的版本编号中,根据第四行来识别PSR   补丁名称 应用对象组成 发布周期 Interim Patch (One-off, PSE) Oracle Database 不定期 Security Patch Update (SPU)  — f.k.a.:CPU Oracle Database 每个季度 Patch Set Updates (PSU) Oracle Database Grid Infrastructure 每个季度 Patch Set Release (PSR) Oracle Database Grid Infrastructure 一年以上或者以上  …

  • 2014年3月21日晚SHOUG上海ORACLE用户组首次线下活动

    2014年3月21日晚SHOUG上海ORACLE用户组首次线下活动,本次活动限制名额50人,如欲参建议尽早报名。 具体时间为:2014年3月21日(周五)晚上18~21时 具体地点为: 中国上海市黄浦区天津路155号名人商业大厦12楼Oracle公司内   本次SHOUG议题如下: 刘相兵 – 《介绍SHOUG的组织宗旨》 40分钟左右 唐涛 – 《介绍ORACLE的大数据解决方案》 40分钟左右 一号店 柳阳 – 《Exadata在电商的实践》   40分钟左右 程飞 – 《oracle常见异常恢复处理思路 》 40分钟左右   按照国际惯例会后将提供presentation的PDF版本,但不提供会议的视频。   下载并填写《SHOUG2014年3月21日活动报名表格》后,请将本报名表格发送到 [email protected],并抄送[email protected][email protected](避免漏看您的邮件)。

  • 【Oracle ASM数据恢复】如何恢复oracleasm deletedisk删除的ASM Disk

    首先注意我们是不推荐用asmlib的,为什么请见Why ASMLIB and why not?   但如果真的遇到了使用asmlib的场景且用户误操作oracleasm deletedisk删除了ASM Disk上的 asmlib标签的话,可以通过下面的步骤来恢复: 1. backup database using RMAN 2. dismount the active Disk group 3. Create KFED following ‘unpublished’ Note 284646.1 Creating and using the kfed utility to view ASM disk header 4. Follow same note to perform kfed read on the affected disk headers. 5. Examine the…

  • ORACLE CHECKLIST FOR CORRUPTION AND DATABASE DOWN

    If you cannot recover data by yourself, ask Parnassusdata, the professional ORACLE database recovery team for help. Parnassusdata Software Database Recovery Team Service Hotline:  +86 13764045638 E-mail: [email protected] STARTUP HANGS If the database hangs on startup: 1.) Instruct the customer to do a STARTUP NOMOUNT (to see if the background processes will start). 2.) Try an…

  • 【转】导致 Scan VIP 和 Scan Listener(监听程序)出现故障的最常见的 5 个问题 (Doc ID 1602038.1)

    【转】导致 Scan VIP 和 Scan Listener(监听程序)出现故障的最常见的 5 个问题 (Doc ID 1602038.1)   适用于: Oracle Database – Enterprise Edition – 版本 11.2.0.1 到 11.2.0.3 [发行版 11.2] 本文档所含信息适用于所有平台 用途 本说明简要总结了导致 SCAN VIP 和 SCAN LISTENERS 故障的最常见问题 适用范围 所有遇到 SCAN 问题的用户 详细信息   问题 1:SCAN VIP 显示状态“UNKNOWN – CHECK TIMED OUT” 在其中一个节点上,SCAN VIP 显示状态“UNKNOWN”和“CHECK TIMED OUT” 另两个 SCAN…

  • 難しいデータベースリカバリプロセス Oracle 11.2はかなり強大

    ORACLEデータベース によくあるエラ の解決策 プロのOracle Databaseの復旧サービスを提供 携帯番号: +86 13764045638 メール:[email protected]   これは単なる自己満足で、何の実な意味もない。ついでに、テストに見つけ出したことも後で述べる(未だにデータベースを起動できていないが、試し続けたいと思う。O(∩_∩)O ~。。。); まずは言うべきなのは11.2の強さである。昔に大部分の場合のエラもリカバリできる。データベースを起動出来たら、損害に関係ないチェックを試す。 1, 11.2から、コントロールファイル自動バックアップが完成した情報はm000によって完成する。それに、ほかの仕事も完成できる。もちろん、別のプロセスが使われる時しか利用できない。 2,DBA_TABLESPACEとV$TABLESPACEの源が違っている。一つ目はコントロールファイルから、もう一つはベーステーブルts$から 3,ts$とfile$が番号をスキップできない。 4,DBMS_HMが強い(Health Manager)。定期的にデータベースにあるものをいちいちチェックして、m000プロセスでtraceを書く。 。。。 主なテストステップはあまり覚えていないが、主なシミュレーションステップは以下の通り: 私の環境: db 11.2.0.3 OEL 5.8 1,二つのテーブルスペースを作成し(一つもいい、数なんかどうでもいい、よりはっきり見えるためだけ)、ログを切り替えて、OSでUNDOTBSを含むデータファイル(普通なデータファイルとundoデータファイルでいい) 2,データベースを起動するときに、ファイルがなくしたあるいは壊された。このとき、エラになったファイルをoffline dropして、データベースが起動できるはず。バックグラウンドにm000によって作成されたtraceがあって、HealthManagerは持続的にm000を引き起こし、ほかの悪い情報をtraceに書き込む。 3,undo$のトラブルロールバックセグメントをクリンアップする 4,新たな普通データのテーブルスペースを作成して、例えば“UNDTBS333”、, UNDO_TABLESPACE=この普通のテーブルスペース(scope=spfile)を設定して、データベースを起動する————–これは当時初めての誤操作だった。 5,データベースがエラになった。具体的な内容も解決策も忘れていた。薄々覚えているのは、undoの隠しバラメタとか、正確なundoテーブルスペース(create undo tablespace …)を作成するだけ。 6,解決したあと、データベースが起動できた。delete from fs$ where name=前に誤操作したあの普通なデータテーブルスペースUNDTBS333’。こうするのはそのとき、リスクを考えず人工的にクリンアップした。 全部で人工的にやってもいいんだが、当時に考えすぎちゃったから、誤操作した。 7,実はこのようなデータベースがまだ起動できるが、DBMS_HM.RUN_CHECK(‘Dictionary Integrity Check’, ‘lunar-ck-Dict’)でテストして、データベースにundo$とts$ がfile$と一致していないが、ほかのデータオブジェクトに影響を与えていない。 けど、頭が熱くなって、二つ目の過ちを犯した:コントロールファイルを再構造する v$tablespaceの内容が誤ったと映されているが、dba_tablespacesが正確だと映している。その定義を検索することで、v$tablespaceのデータはx$kcctsというベーステーブルから獲得できた。つまりコントロールファイルの情報から。それにdba_tablespacesはts$を元にしているから、コントロールファイルを再構造するという愚かな発想が生み出した。 8,コントロールファイルのプロセス自体が誤った、.。わかるよね。。。もちろん、後でこのトラブルを避けた。具体的なステップを忘れたが、いいんだ。別に難しくないから。 9,再びデータベースを救出できなかった 。。。。。 このプロセスは以下の文にエラがあった。Oracle2進数ファイルをテストすることで、みつかりやすい。これはデータベースを起動するときに、file$に対してインサートするから、つまり、bootstrap$によって、file$のブロックを見つけ出す。そのすべての内容をこのテーブルにインサートする: select blocks,NVL(ts#,-1),status$,NVL(relfile#,0),maxextend,inc,…

  • oracle DUL第二篇——DULでdmpファイルを抽出する

    ORACLEデータベース によくあるエラ の解決策 プロのOracle Databaseの復旧サービスを提供 携帯番号: +86 13764045638 メール:[email protected]   Dulによく使われるコマンド: DUL> unload database ; DUL> unload user ; DUL> unload table ; DUL> scan database; DUL> scan tables; テストテーブルの記録数を記してください:   SYS@lunar>select count(*) from lunar.lunar; COUNT(*) ———- 17634 ここでは17634 行記録である Elapsed: 00:00:00.09 SYS@lunar> ほかの配置バラメタは第一篇に参考してくださいDUL 第一篇 —— DULは何か? DULを起動してunpump headerを実行すれば、抽出できる: DUL> unpump header dump file lunar.01.dmp; Version is…

  • Oracle ORA-00604とORA-04024エラの解決策

    ORACLEデータベース によくあるエラ の解決策 プロのOracle Databaseの復旧サービスを提供 携帯番号: +86 13764045638 メール:[email protected]   一般的なOracleのbootstrap index(テーブルのインディクスと一部のコアオブジェクトをガイドする)も似たような方法で対応できる。例えば以下のクエリ文のI_OBJxxxxx。 . テスト環境 11.2.0.3データベース:   [oracle@lunarpri ~]$ ss SQL*Plus: Release 11.2.0.3.0 Production on Fri Mar 27 19:12:57 2015 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production With the Partitioning and Real Application…