Month: November 2014

データベースの文字セットが分からなかったらどうすればいい？     Oracleアラームロゴalert.logを確認することによって、データベースの文字セットが確認できる。例えば：   [oracle@mlab2 trace]$ grep  -i character alert_Parnassus.logDatabase Characterset is US7ASCII Database Characterset is US7ASCII alter database character set INTERNAL_CONVERT AL32UTF8 Updating character set in controlfile to AL32UTF8 Synchronizing connection with database character set information Refreshing type attributes with new character set information Completed: alter database character set INTERNAL_CONVERT AL32UTF8 alter database…

Ｄ社のアプリ開發者がASMの環境で、なんのバックアップもないのに、システムの肝心なアプリテーブルをDROPした。そのときに、ＰＲＭですぐに大部分のデータをリカバリできる。10gのあと、recyclebinゴミ箱を追加した。まずはDBA_RECYCLEBINSビューを確認して、DROPしたテーブルがそこにあるか否かをたしかめる。もしそこにもなかったら、ＰＲＭでリカバリしてください。     リカバリの流れは以下の通り：   まずはDROPされたデータテーブルを含むテーブルスペースを見つけ出す。 ディクショナリーをけんさくして、あるいはLOGMINERでDROPされたデータテーブルのDATA_OBJECT_IDを見つけ出す。DATA_OBJECT_IDを得られない場合にはNON-DICTモードでＰＲＭを起動する。DROPされたデータテーブルを含むテーブルスペースにすべてのフィルタを追加したら、SCAN DATABASE+SCAN TABLE from Extent MAP。 DATA_OBJECT_IDによって、データテーブルを見つけて、DataBridgeモードでもとのデータベースに伝送する。   SQL> select count(*) from “MACLEAN”.”TORDERDETAIL_HIS”;  COUNT(*) ———- 984359   SQL> SQL> create table maclean.TORDERDETAIL_HIS1 as select * from  maclean.TORDERDETAIL_HIS;   Table created.   SQL> drop table maclean.TORDERDETAIL_HIS;   Table dropped.         Logminerに通って、あるいはリカバリシーン9の方法で大抵なDATA_OBJECT_IDを得られる、LOGMINERを利用するスクリプトは以下の通り：   EXECUTE DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => ‘/oracle/logs/log1.f’,…

Ｄ社の職員があるいらないテーブルスペースを削除したいだが、つまりDROP TABLESPACE INCLUDING CONTENTS操作で、DROP TABLESPACEを実行したら、開發者がDROPされたTABLESPACEにSCHEMAという重要なデータがあるが、テーブルスペースがDROPされて、バックアップもないので、まさに万策尽きという状態である。     こういう時にやくに立てるのはＰＲＭのNo-Dictモードで、DROP TABLESPACEされたすべてのフィルタを抽出してください。多くのデータがこの方法でリカバリできると思うが、非ディクショナリーモードなので、もう一度リカバリしてきたデータとアプリデータテーブルを対応する必要がある。この時に、アプリ開發者の協力が必要で、データはどこのテーブルに属しているのか人工的に判明する必要がある。DROP TABLESPACE操作がデータディクショナリーを変更した上で、OBJ$で該当するテーブルスペースの目標を削除したから、OBJ$からDATA_OBJECT_IDとOBJECT_NAMEの間の関係を得られない。この時に、以下の方法を活かし、DATA_OBJECT_IDとOBJECT_NAMEの関係をより多く手に入ることができる。     select tablespace_name,segment_type,count(*) from dba_segments where owner=’PARNASSUSDATA’  group by tablespace_name,segment_type;    TABLESPACE SEGMENT_TYPE      COUNT(*) ———- ————— ———- USERS      TABLE                  126 USERS      INDEX                  136   SQL> select count(*) from obj$;   COUNT(*) ———- 75698     SQL> select current_scn, systimestamp from v$database;   CURRENT_SCN ———–…

Ｄ社の技術者は誤操作で一番大事なデータベースのSYSTEMテーブルスペースFILE#=1のフィルタと一部のアプリテーブルスペースを削除したことによって、データベースが順調に起動できない。     このシーンでPRMの《Non-Dictionary Mode(ASM) 》ASMの非ディクショナリーモードによって、今のデータフィルタに基づき、いちはやくデータをリカバリできる。   簡単な流れは以下の通り：     Recovery Wizard Dictionary Mode(ASM) 必要なASM DISKを追加し（リカバリしたいデータベースを含むASM Disk GroupにすべてのASM DISK） ASM analyze クリックする あとのフィルタのために、ふさわしいEndianを選ぶ。（非ディクショナリーモードなので、人工で選ぶ必要がある）。 ASM analzeのフィルタリストで必要とするデータフィルタを選んでください。一つのリポジトリしかない場合に、Select allを選んでください。 ロードをクリックして、後のリカバリはシーン３に似ている。        

Ｄ社の一番大事なCRMリポジトリがASM Diskgroupに追加したディスクがI/O問題があるから。SYSTEMテーブルスペースのDBFデータフィルタがエラになり、データベースが正常に起動できない。   この時はPRMを通って、ASM DiskgroupからDATAFILEを全部フィルタシステムにコーピーして、リカバリシーン６のように、データベースを修復する。   ＰＲＭのDictionary Mode(ASM)もASMのディクショナリーモードで問題を解決できる。簡単な流れは以下の通り：   Recovery Wizard Dictionary Mode(ASM) 必要なASM DISKを追加し（リカバリしたいデータベースを含むASM Disk GroupにすべてのASM DISK） ASM analyze クリックする あとのフィルタのために、ふさわしいEndianを選ぶ。 ASM analzeのフィルタリストで必要とするデータフィルタを選んでください。一つのリポジトリしかない場合に、Select allを選んでください。 ロードをクリックして、後のリカバリはシーン３に似ている。          

Ｄ社はASM方法でフィルタシステムとRAWデバイスをかわったが、いま運用しているのは11.2.0.1バーションで、bugが多いので、ASM DISKGROUPディスくがMOUNTをロードできなくて、いろんな手を打ったが、なかなか効果が出ない。   このシーンで使えるのはＰＲＭのASM Files Cloneフィルタコーピー機能です。この機能はダンメージを受けたASM Diskgroupからデータベースフィルタをコーピーできる。 1.インタフェースをオープンして、ToolsメニューコラムでASM File(s) Cloneを選んでください。:     ASM Disksに入って、SELECT…をクリックして、使用可能なASM Disksを追加する。例えば、/dev/asm-disk5(linux)。すべての使用可能なLUNを追加した後、ASM analyzeボタンをクリックしてください。       ASM analyzeがDisk groupの中のフィルタとアドレス(File Extent Map)を見つけ出すために、指定されたASM Diskのディスクヘッダーを分析する。これらのデータは以後も使えるように、Derbyデータベースに記録される。ここで、ＰＲＭはASMあらゆるのMetadataを収集して分析して格納する。そして、いろいろな方法でＰＲＭの基本的な機能を改善し、グラフの形式でユーザーに示す。     ASM Analyzeが完成したら、ＰＲＭは探し出したASMのフィルタをリストにする。どれをコーピーする必要があるか、ユーザーが自分で決めて、コーピー先を指定することもできる。   コーピー段階で、ASM Fileのコーピー進捗状況を示されて、完成したら、OKをクリックしてください。           コーピー段階の進捗状況は以下のようにエクスポートする。   Preparing selected files…  Cloning +DATA2/ASMDB1/DATAFILE/TBS2.256.839732369: ……………………..1024MB ………………………………..2048MB ………………………………..3072MB ………………………………….4096MB ………………………………..5120MB ………………………………….6144MB ……………………………….7168MB …………………………………8192MB …………………………………9216MB …………………………………10240MB …………………………………11264MB…

Ｄ社のＳAシステム管理員があるデータベースのSYSTEMテーブルスーペスのフィルタを削除したことによって、データベースがうまく起動せず、データを取り出せない。でも、たとえバックアップがなくても、ＰＲＭで１００％に近いデータをリカバリできる。   此场景中启动PRM后，进入Recovery Wizard后 选择《Non-Dictionary mode》非字典模式:このシーンでＰＲＭを起動したら、Recovery Wizardに入ったら、Non-Dictionary modeを選んでください：       No-dictionaryモードでユーザーが文字セットと各国語キャラクタ・セットを指定する必要がある。システムテーブルスペースをなくした後、データベース情報の文字セットが正確に獲得できないから、ユーザーの入力が必要になる。正確に文字セットを設置したことと必要な言語パックをインストールしたことはNo-Dictionaryモードで、順調に多国語を抽出する保障である。   シーン１と同じように、いまユーザーが獲得可能なすべてのフィルタを入力し（一時的なフィルタを含まない）、正確にBlock SizeとOFFSETを設置してください：     そして、SCANをクリックしてください。SCANの役目はすべてのフィルタのSegment Headerをスキャンし、SEG$.DATとXT$.DATに記録する。Oracleの中で、一つの非パーティション表とパーティション表はテーブルデータセグメントのEXTENT MAP情報に該当する、EXTENT MAPによって、そのテーブルにすべての記録を手に入れる。   また、一つの非パーティション表をある二つのフィルタによって構造したテーブルスペースに格納し、そのSEGMENT HEADERと半分のデータがAフィルタに格納し、その ほかの半分がBフィルタに格納する。だが、ある事情によってSYSTEMテーブルスペースもSEGMENT HEADERを格納したAフィルタもなくし、Ｂフィルタしか残っていない場合に、ただＢフィルタのデータをリカバリしたいとすれば、SEGMENT HEADERに頼らず、ＢフィルタのEXTENT MAPの情報に頼るしかない。     SEGMENT HEADERに基づく和EXTENT MAPデータのNO-Dictionaryモードのリカバリ需要を同時に満たすために、SCAN操作はここでSEG$.DATとEXT$.DATに書き込み、（テキストフィルタは診断しやすくなるため、すべてのプログラムはＰＲＭ自身が持ち込むDERBYに頼っている。）そしてDERBYデータベースに記録する。       SCANを完成したら、インタフェースの左側にデータベースアイコンが現れる。   この時、二つのバッタンを選べる。：   Scan Tables From Segments、このバッタンは： システムテーブルスペースをなくしたが、すべての応用データテーブルスペースが存在している場合に適応している。 Scan Tables From Extents DictionaryモードのTruncateテーブルデータリカバリに適応していない。 システムテーブルスペースをなくしたにかかわらず、SEGMENT HEADERを格納したフィルタもなくした場合に適応している。   簡単にいうと、シーン２の方法でTRUNCATEされたデータをリカバリできないに限って、それ以外の場合はScan Tables…

Ｄ社のＤＢAは誤操作でTS$データディクショナリーを削除したため、データベースが起動できない。   Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit ProductionWith the Partitioning, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options     INSTANCE_NAME —————- ASMME   SQL> SQL> SQL> select count(*) from sys.ts$;   COUNT(*) ———- 5   SQL> delete ts$;   5 rows deleted.   SQL> commit;   Commit…

Download PRM-DUL: http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip 概述  サマリー   ParnassusData Recovery Manager（以下略してＰＲＭ）は企業レベルのOracleデータディザスタリカバリーソフトで、OracleデータベースのインスタンスでＳＱＬを実行することじゃなく、直接にOracle9i,10g,11g,12cからデータベースのデータフィイルを抽出することにより、目標データを救うソフトである。ParnassusData Recovery ManagerはJavaに基づいて開発された安全性が高く、ダウンロードして解凍したあと、インストールすることなしにそのままで運用できて、とっても便利で使いやすいなソフトである。 ＰＲＭはGUIグラフィカルインターフェース（図１）を採用し、新たなプログラミング言語をあらかじめ勉強する必要はなく、Oracle　bottom-level structure of database原理さえわかっていれば、リカバリーウィザード(Recovery Wizard)を使うことによって、データをリカバリーできる。   なぜＰＲＭを使う必要があるでしょう？   お客様きっとまだこういう疑問を抱いているでしょう：「RMANという応用歴史が長いOracleリカバリーマネジャーのバックアップによるリカバリーはまだ足りないというのか。なぜわざわざPRMを買う必要があるでしょう。」   ご存知の通りですが、今企業に発展し続けていくITシステムでは、データボリュムがまさに日進月歩である。データの整合性を確保することは何より大事ですが、このデータが爆発的に増加する時代のなか、今日のOracle DBAたちは既存のディスクボリュムが不足で、データ全体を格納できないやテープによるバックアップがリカバリーするときに要する時間が予想した平均修復時間に超えていたなどさまざまな課題に直面している。   「データベースにとって、バックアップは一番大事である」ということわざはあらゆるDBAのこころに刻んでいる。けど、現実の環境は千差万別で、筆者の経験では、企業データベース環境でバックアップスペースが足りないとか、購入したストレージデバイスが短期的に手に入ることができないとか、バックアップしていたが、実際にリカバリーしているとき、使えなくなったとか、現場に起きることが実に予想できない。   現実によくあるリカバリートラブルに対応するため、PRM 诗檀データベースリカバリーマネジャーソフトは開発された。PRM 诗檀データベースリカバリーマネジャーソフトはORACLEデータベース内部データ構造理解したうえで、全くバックアップしていないときにSYSTEMテーブルスペースなくしたとか、ORACLEデータディクショナリーテーブルを誤操作したとか、電源がきれたことによりデータディクショナリー一貫性をなくし、データベースを起動できないとか、さまざまな難題に対応できる。さらに、誤切断(Truncate)/削除 (Delete)業務データテーブルなど、人為的な誤操作もリカバリーできる。   Oracle専門家に限っていることじゃなく、わずか数日間しかOracleデータベースを接触していなかった方にも自由自在に運用できる。このすべてはＰＲＭのインストールがとびきりたやすいところとグラフィカル対話型インタフェースのおかげです。これにより、リカバリーを実行する技術者たちはデータベースに関する専門知識を要することじゃなく、あらためて新たなプログラミング言語を勉強する必要もない。データベースの基礎になる格納構造についてはなおさらです。マウスをクルックするだけで、余裕をもってリカバリーできる。   伝統的なリカバリーツールであるDULにたいして、ＰＲＭはDULがかなわない強みをもっている。DULはOracleオリジナル内部リカバリーツールであて、使うたびに必ずOracle内部プロセスに通する。一般的に、Oracle現場技術サポートを購入した少しのユーザーがOracle会社から派遣されたエンジニアの支援の元に、リカバリー作業が始められる。ＰＲＭは少数の専門家しかデータベースリカバリー作業しか務められないという現実を一新し、データベースがトラブルを起きる時点からリカバリー完了するまでの時間を大幅に短縮したから、企業のリカバリーコストを大分軽減した。   ＰＲＭを通ってリカバリーするには二つパータンにわけている。伝統的な抽出方法として、データをファイルから完全抽出して、フラットテキストファイルに書き入れて、そしてSQLLDRなどツールでデータベースへロードする。伝統の使い方がわかりやすいが、既存二倍のデータボリュームのスペースを要求するというデメリットがある。つまり、ひとつのフラットテキストファイルが占めているスペースとあとでテキストデータをデータベースにロードするスペース。時間についても、元のデータをファイルから抽出したから、新規データベースにロードできるため、常に二倍の時間を必要としている。   もう一つはわたしたちＰＲＭにより、独創的なデータバイパスモード、つまりＰＲＭを通ってじかにデータを抽出し、新規や他の使用可能なデータベースにロードする。これより、着陸データストレージに避けて、伝統の方法に比べて、さらに時間もスペースも節約できる。   いま、Oracle　ASMの自動ストレージ管理技術はより多くの企業により採用されて、このシステムは伝統のファイルシステムよりずっと多くのメリットをもっている。例えば、性能がより高く発揮できるところ、クラスタを支持しているところ、そして管理するとき、とても便利のところ。でも、普通のユーザーにとって、ASMの格納構造があんまりにわかりにくく、いざASMであるDisk Groupの内部データ構造が故障になって、Disk GroupがMOUNTできなくなる。つまり、ユーザーたち大事なデータをASMに閉じ込まれた。こういうときは、必ずASM内部構造に詳しいOracle会社の専門家を現場に要請して、手動的にトラブルを解決する術しかない。でも、Oracle会社の現場技術サポートを買うには大量な資金が必要としている。   そこで、ＰＲＭの開発者（前Oracle会社シニアエンジニア）はOracle　ASM内部データ構造に対する幅広い知識に基づき、ＰＲＭでは、ASMに対するデータリカバリー機能を追加した。   今ＰＲＭが支持しているASMに対するデータリカバリー機能は以下ご覧のとおり：   1.　　たとえDisk Groupが正常にMOUNTできなくても、ＰＲＭを通って、ASMディスクに使用可能なメタデータを読み取ることができる、さらにこれらのメタデータがDisk GroupにあるASMファイルをコーピーすることもできる。   2.　　たとえDisk Groupが正常にMOUNTできなくても、ＰＲＭを通って、ASMにあるデータファイルを読み取ることやそのまま抽出することも支持する。抽出する方法については、伝統的な抽出方法とデータバイパスモード両方も支持している。     ＰＲＭソフト紹介…

在本次中#2014年Orcl-Con甲骨文控活动#引入了一个利用12c in-memory特性优化查询语句的workshop ，在不考虑索引等特性的前提下，仅仅使用12c IMCC特性，崔胄同学利用inmemory和并行特性将原本需要1分钟运行的SQL，优化到1.37秒，提升数十倍，成功赢得ipad! 该次SQL优化比拼的 原帖地址http://t.cn/RzURLTJ     OKAY 我们来优化一下, 既然索引，物化视图等传统技术无法使用，我们只能使用使用一些oracle的大数据处理技术来提高性能 首先创建表 scripts 可以查看 xxxxxxxx 这里提一下, 在创建表的时候使用pctfree 0 来适当的降低了逻辑读。 创建完毕 COUNT(*)||’TIME_ROWS’ 58432 time_rows 29402976 sales_rows 1776000 customers_rows 160 channles_rows 创建完后 跑了一下 no tuning 172706 consistent gets Elapsed: 00:00:22.11 oooooopss~ 22秒 看来需要优化 开始使用 in-memory 组件 来优化 SQL> select * from v$version; BANNER Oracle Database 12c Enterprise Edition…