AMDU-- ASM文件转移工具
近日遇到一个问题,就是ASMdiskgroup无法挂载,通过分析之后,发现有会快存在,但是由于没有备份,没有办法重建diskgroup并从backup恢复--所以所以所以....备份
近日遇到一个问题,就是ASM diskgroup无法挂载,通过分析之后,发现有会快存在,,但是由于没有备份,没有办法重建diskgroup并从backup恢复--所以所以所以....备份很重要啊!不然,哭!!是早晚的事情!
通过解决这个问题,我在自己的测试环境测试了如何在ASM diskgroup无法mount的情况下,尽量挽救数据文件。
这里使用到oracle 工具AMDU,该具体信息可以参考AMDU functionality and usage (Doc ID 855791.1)
1. 由于diskgroup无法挂载,SPFILE、CONTROLFILE、DATAFILE都无法读取
根据步骤,我们首先需要恢复spfile文件,spfile文件存在的意义就是找到control_files的位置,如果spfile无法访问,需要查找备份。
SQL> show parameter control_files +DATA/db/controlfile/current.260.804295233, +FRA/db/controlfile/current.256.804295237
2. 通过ASM实例找到asm_diskstring
SQL> show parameter disk NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ asm_diskgroups string DATA, FRA asm_diskstring string /dev/sd*
3. 查找asm disk的路径,后续要指定diskstring来扫描磁盘
SQL> select NAME,STATE,TYPE,OFFLINE_DISKS,VOTING_FILES from v$asm_diskgroup; SQL> col PATH for a50 SQL> col name for a10 SQL> set line 200 SQL> select DISK_NUMBER,GROUP_NUMBER,PATH,name from v$asm_disk; DISK_NUMBER GROUP_NUMBER PATH NAME ----------- ------------ -------------------------------------------------- ---------- 1 2 /dev/oracleasm/disks/ASMDISK5 FRA_0001 0 2 /dev/oracleasm/disks/ASMDISK4 FRA_0000 2 1 /dev/oracleasm/disks/ASMDISK3 DATA_0002 DISK_NUMBER GROUP_NUMBER PATH NAME ----------- ------------ -------------------------------------------------- ---------- 1 1 /dev/oracleasm/disks/ASMDISK2 DATA_0001 0 1 /dev/oracleasm/disks/ASMDISK1 DATA_0000
4. 在diskgroup mount状态,是不能使用amdu导出文件的
执行amdu命令开始导出,遇到错误
$ amdu -diskstring '/dev/oracleasm/disks/ASMDISK*' -extract data.260 amdu_2013_07_03_17_29_13/ AMDU-00204: Disk N0005 is in currently mounted diskgroup DATA AMDU-00201: Disk N0005: '/dev/oracleasm/disks/ASMDISK1'
检查发现磁盘组mount
$ crsctl status res -t -------------------------------------------------------------------------------- NAME TARGET STATE SERVER STATE_DETAILS -------------------------------------------------------------------------------- ora.DATA.dg ONLINE ONLINE single-db ora.FRA.dg ONLINE ONLINE single-db
5. 导出控制文件
$ amdu -diskstring '/dev/oracleasm/disks/ASMDISK*' -extract data.260 amdu_2013_07_03_17_46_07/ [oracle@Single-DB amdu]$ cd amdu_2013_07_03_17_46_07/ [oracle@Single-DB amdu_2013_07_03_17_46_07]$ ls DATA_260.f report.txt
6. 尝试挂载control file
发现spfile也存放在磁盘组中无法nomount
$ sqlplus / as sysdba SQL> startup nomount; ORA-01078: failure in processing system parameters ORA-01565: error in identifying file '+DATA/db/spfiledb.ora' ORA-17503: ksfdopn:2 Failed to open file +DATA/db/spfiledb.ora ORA-15056: additional error message ORA-17503: ksfdopn:DGOpenFile05 Failed to open file +DATA/db/spfiledb.ora ORA-17503: ksfdopn:2 Failed to open file +DATA/db/spfiledb.ora ORA-15001: diskgroup "DATA" does not exist or is not mounted ORA-06512: at line 4
7. 那就编辑一个新的pfile文件
$ cp init.ora spfilebk.ora $ vi spfilebk.ora ~~~~~~~~~~~~~~~ db_name='DB' sga_target=1G processes = 150 audit_trail ='db' db_block_size=8192 db_domain='' db_recovery_file_dest_size=2G open_cursors=300 remote_login_passwordfile='EXCLUSIVE' undo_tablespace='UNDOTBS1' control_files = /u01/amdu/amdu_2013_07_03_17_46_07/DATA_260.f compatible ='11.2.0' ~~~~~~~~~~~~~~~
8. 通过导出的控制文件启动数据库到mount模式,成功启动,说明AMDU导出的数据时正确的,继续。。。。。
$ sqlplus / as sysdba SQL> startup nomount pfile='/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfilebk.ora'; ORACLE instance started. Total System Global Area 1068937216 bytes Fixed Size 2220200 bytes Variable Size 281022296 bytes Database Buffers 780140544 bytes Redo Buffers 5554176 bytes SQL> alter database mount; Database altered.
9. 查看数据文件的位置,然后一一导出
SQL> select name from v$datafile; NAME -------------------------------------------------------------------------------- +DATA/db/datafile/system.256.804295135 +DATA/db/datafile/sysaux.257.804295137 +DATA/db/datafile/undotbs1.258.804295139 +DATA/db/datafile/users.259.804295141 $ amdu -diskstring '/dev/oracleasm/disks/ASMDISK*' -extract data.256
10. 重命名数据文件,并移动到同一个目录下,准备挂载数据文件
$ mv amdu_2013_07_03_18_12_56/DATA_257.f sysaux.257.804295137 $ mv amdu_2013_07_03_18_22_23/DATA_259.f users.259.804295141 $ mv amdu_2013_07_03_18_23_06/DATA_258.f undotbs1.258.804295139 $ ll -rw-r--r-- 1 oracle dba 545267712 Jul 3 18:14 sysaux.257.804295137 -rw-r--r-- 1 oracle dba 702554112 Jul 3 18:11 system.256.804295135 -rw-r--r-- 1 oracle dba 99622912 Jul 3 18:23 undotbs1.258.804295139 -rw-r--r-- 1 oracle dba 5251072 Jul 3 18:22 users.259.804295141
11. 挂载前需要修改pfile文件,下面是open数据库是control file如何识别不同路径的datafile, 我使用convert参数来解决(也可以是用set newname的方式)
db_file_name_convert='+DATA/db/datafile','/u01/amdu/amdu_datafile'
添加完pfile,启动数据库,最终成功启动数据库

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











完全なテーブルスキャンは、MySQLでインデックスを使用するよりも速い場合があります。特定のケースには以下が含まれます。1)データボリュームは小さい。 2)クエリが大量のデータを返すとき。 3)インデックス列が高度に選択的でない場合。 4)複雑なクエリの場合。クエリプランを分析し、インデックスを最適化し、オーバーインデックスを回避し、テーブルを定期的にメンテナンスすることにより、実際のアプリケーションで最良の選択をすることができます。

INNODBのフルテキスト検索機能は非常に強力であり、データベースクエリの効率と大量のテキストデータを処理する能力を大幅に改善できます。 1)INNODBは、倒立インデックスを介してフルテキスト検索を実装し、基本的および高度な検索クエリをサポートします。 2)一致を使用してキーワードを使用して、ブールモードとフレーズ検索を検索、サポートします。 3)最適化方法には、単語セグメンテーションテクノロジーの使用、インデックスの定期的な再構築、およびパフォーマンスと精度を改善するためのキャッシュサイズの調整が含まれます。

はい、MySQLはWindows 7にインストールできます。MicrosoftはWindows 7のサポートを停止しましたが、MySQLは引き続き互換性があります。ただし、インストールプロセス中に次のポイントに注意する必要があります。WindowsのMySQLインストーラーをダウンロードしてください。 MySQL(コミュニティまたはエンタープライズ)の適切なバージョンを選択します。インストールプロセス中に適切なインストールディレクトリと文字セットを選択します。ルートユーザーパスワードを設定し、適切に保ちます。テストのためにデータベースに接続します。 Windows 7の互換性とセキュリティの問題に注意してください。サポートされているオペレーティングシステムにアップグレードすることをお勧めします。

MySQLは、オープンソースのリレーショナルデータベース管理システムです。 1)データベースとテーブルの作成:createdatabaseおよびcreateTableコマンドを使用します。 2)基本操作:挿入、更新、削除、選択。 3)高度な操作:参加、サブクエリ、トランザクション処理。 4)デバッグスキル:構文、データ型、およびアクセス許可を確認します。 5)最適化の提案:インデックスを使用し、選択*を避け、トランザクションを使用します。

クラスター化されたインデックスと非クラスター化されたインデックスの違いは次のとおりです。1。クラスター化されたインデックスは、インデックス構造にデータを保存します。これは、プライマリキーと範囲でクエリするのに適しています。 2.非クラスター化されたインデックスストアは、インデックスキー値とデータの行へのポインターであり、非プリマリーキー列クエリに適しています。

MySQLデータベースでは、ユーザーとデータベースの関係は、アクセス許可と表によって定義されます。ユーザーには、データベースにアクセスするためのユーザー名とパスワードがあります。許可は助成金コマンドを通じて付与され、テーブルはCreate Tableコマンドによって作成されます。ユーザーとデータベースの関係を確立するには、データベースを作成し、ユーザーを作成してから許可を付与する必要があります。

MySQLとMariaDBは共存できますが、注意して構成する必要があります。重要なのは、さまざまなポート番号とデータディレクトリを各データベースに割り当て、メモリ割り当てやキャッシュサイズなどのパラメーターを調整することです。接続プーリング、アプリケーションの構成、およびバージョンの違いも考慮する必要があり、落とし穴を避けるために慎重にテストして計画する必要があります。 2つのデータベースを同時に実行すると、リソースが制限されている状況でパフォーマンスの問題を引き起こす可能性があります。

MySQLは、Bツリー、ハッシュ、フルテキスト、および空間の4つのインデックスタイプをサポートしています。 1.B-Treeインデックスは、等しい値検索、範囲クエリ、ソートに適しています。 2。ハッシュインデックスは、等しい値検索に適していますが、範囲のクエリとソートをサポートしていません。 3.フルテキストインデックスは、フルテキスト検索に使用され、大量のテキストデータの処理に適しています。 4.空間インデックスは、地理空間データクエリに使用され、GISアプリケーションに適しています。
