SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

Archive for 9月 4th, 2009

トランザクションログが壊れるとバックアップまで戻すしかない??

with 2 comments

いろいろと話題になっている [中堅企業向け オラクル都市伝説- シーズン2] ですが、記事の中に以下の記載があります。

ログファイルが壊れるとデータの復旧ができない。
毎日夜中にバックアップを取っていたが、データはバックアップした状態、すなわち昨日の夜の時点に戻ってしまう。
ユーザーがショッピングサイト上で行っていた直近の購入情報が損失してしまうのだ。ショッピングサイト運営会社は夜間に社員を緊急収集し、損失したデータを手作業で入力するはめになった。その他、クレーム対応のため、膨大な損失を被むる。
まさに地獄である。

?

ログファイルが壊れ、データの復旧ができなくなったため、バックアップまで戻したとあります。

トランザクションの整合性が保たれた状態に戻すということを考えるとこの対応は正しいと思いますが、
障害発生時では、それまでのデータを何とかして確認する方法がないかということも重要だと思います。

SQL Server はトランザクションログファイルが壊れてもデータファイルが生きていれば状況によってはある程度は復旧できます。

といことで実験してみました。

[トランザクションログを壊す]

まずは、トランザクションログを壊さないと話が始まりません。
とりあえず、バイナリエディタを使用してファイルの内容を 0 クリアしてみました。
データベースは SQL Server 2000 の Northwind を使用しています。
?

[データベースは障害状態になる?]

この状態のデータベースを SQL Server 2000 で開くとどうなるか確認してみました。
image

データベースが開けちゃうんですね・・・。
DBCC で確認してもエラーにはなりませんでした。

[トランザクションログのファイル自体を削除する]

続いては ldf を削除してデータファイルだけの状態にしてみました。
これもまた起動してきちゃうんですね。

image

SQL Server が起動時に新しいトランザクションログを作っていました。

image

[トランザクションログファイルを壊れた状態にするには?]

壊さないことには検証が始まらなさそうですので、ひとまず復旧間隔を 20 分に設定し、10,000 件のデータを挿入して、
サーバーを強制シャットダウンして、トランザクションログを FF でクリアしてみました。

どうやらトランザクションログを壊すことに成功したようです。
# SQL Server 2000 / 2008 でこの方法でログを壊すことができました。
?image

さて、これで都市伝説と同じ状態に持っていくことができました。
ここから、データを復旧したいと思います。

[ログの再構築でデータを復旧]

SQL Server 2000 と 2005 以降ではログの復旧方法が異なります。

[SQL Server 2000]
SQL Server 2000 で復旧する場合は、システムテーブルを直接更新して、EMERGENCY モードに設定する必要があります。
SQL Server 2000 の DBCC にはログを再構築するコマンドがあります。
REBUILD_LOG コマンドで新しいログファイルが作成できます。このコマンドは Undocumented な DBCC なんですよね。

2000 では REPAIR_ALLOW_DATA_LOSS でログファイルを再構築することができないので、REBUILD_LOG コマンドを
使用してログファイルの再構築をする必要があります。

sp_configure ‘allow updates’,1
GO
RECONFIGURE WITH OVERRIDE
GO
UPDATE sysdatabases SET status = 32768 WHERE name = N’Northwind’
GO

ALTER DATABASE [Northwind] SET SINGLE_USER
GO
DBCC REBUILD_LOG(‘Northwind’,’C:Program Files (x86)Microsoft SQL ServerMSSQL$SQL2000DataNorthwind.LDF’)
GO
ALTER DATABASE [Northwind] SET MULTI_USER
GO
sp_configure ‘allow updates’,0
GO
RECONFIGURE WITH OVERRIDE
GO

設定オプション ‘allow updates’ が 0 から 1 に変更されました。RECONFIGURE ステートメントを実行して、インストールしてください。

(1 行処理されました)
警告 : データベース ‘Northwind’ のログが再構築されました。トランザクションの一貫性は失われます。DBCC CHECKDB を実行して物理的な一貫性を調べる必要があります。データベース オプションを再設定し、余分なログ ファイルを削除する必要があります。
DBCC の実行が完了しました。DBCC がエラー メッセージを出力した場合は、システム管理者に相談してください。
設定オプション ‘allow updates’ が 1 から 0 に変更されました。RECONFIGURE ステートメントを実行して、インストールしてください。

[SQL Server 2005 以降]
SQL Server 2005 以降では ALTER DATABASE で EMERGENCY モードに設定することができます。
また、2005 以降では DBCC CHECKDB を REPAIR_ALLOW_DATA_LOSS で実行することとで
トランザクションログの再作成ができます。
# REBUILD_LOG は使えなくなっています。

AL
TER DATABASE [Northwind] SET EMERGENCY
GO
ALTER DATABASE [Northwind] SET SINGLE_USER
GO
DBCC CHECKDB (‘Northwind’, REPAIR_ALLOW_DATA_LOSS)
GO
ALTER DATABASE [Northwind] SET MULTI_USER
GO

?

ファイル アクティブ化エラー。物理ファイル名 "C:Program FilesMicrosoft SQL ServerMSSQL10.SQL2008MSSQLDATAnorthwnd.ldf" が正しくない可能性があります。
データベースのシャットダウン時に開いているトランザクション/ユーザーがあったか、データベースにチェックポイントが発生していないか、またはデータベースが読み取り専用のため、ログを再構築できません。このエラーは、トランザクション ログ ファイルが手動で削除されたか、ハードウェアまたは環境の障害により失われた場合に発生する可能性があります。
警告: データベース ‘Northwind’ のログが再構築されました。トランザクションの一貫性は失われました。RESTORE チェーンが壊れ、サーバーが以前のログ ファイルのコンテキストを保持しなくなったので、以前のログ ファイルについて把握しておく必要があります。DBCC CHECKDB を実行して物理的な一貫性を検証してください。データベースは dbo 専用モードに設定されました。データベースが使用可能な状態になったら、データベース オプションを再設定し、余分なログ ファイルを削除してください。
‘Northwind’ の DBCC 結果。
Service Broker メッセージ 9675、状態 1: 分析されるメッセージ型: 14。
Service Broker メッセージ 9676、状態 1: 分析されるサービス コントラクト: 6。
Service Broker メッセージ 9667、状態 1: 分析されるサービス: 3。
Service Broker メッセージ 9668、状態 1: 分析されるサービス キュー: 3。
Service Broker メッセージ 9669、状態 1: 分析されたメッセージ交換のエンドポイント: 0。
Service Broker メッセージ 9674、状態 1: 分析されたメッセージ交換グループ: 0。
Service Broker メッセージ 9670、状態 1: 分析されるリモート サービス バインド: 0。
Service Broker メッセージ 9605、状態 1: 分析されたメッセージ交換の優先度: 0。
‘sys.sysrscols’ の DBCC 結果。
オブジェクト "sys.sysrscols" の 10 ページには 785 行あります。

~ 省略 ~

‘Suppliers’ の DBCC 結果。
オブジェクト "Suppliers" の 1 ページには 29 行あります。
CHECKDB により、データベース ‘Northwind’ に 0 個のアロケーション エラーと 0 個の一貫性エラーが見つかりました。
DBCC の実行が完了しました。DBCC がエラー メッセージを出力した場合は、システム管理者に相談してください。
メッセージ 824、レベル 24、状態 2、行 1
SQL Server で、一貫性に基づいた論理 I/O エラーが検出されました: 無効な保護オプション。このエラーは、ファイル ‘C:Program FilesMicrosoft SQL ServerMSSQL10.SQL2008MSSQLDATAnorthwnd.ldf’ のオフセット 0000000000000000 にあるデータベース ID が 7 のページ (2:0) の 読み取り 中に発生しました。SQL Server エラー ログまたはシステム イベント ログ内の別のメッセージで詳細情報が報告されることもあります。このエラー状態は深刻で、データベースの整合性を損なう可能性があるので、すぐに解決する必要があります。完全なデータベース一貫性確認 (DBCC CHECKDB) を実行してください。このエラーには多くの要因があります。詳細については、SQL Server オンライン ブックを参照してください。

このような形でログファイルが破損していても、データファイルのデータは復旧することが可能です。

SQL Server 2000 / 2005 / 2008 ではログの再構築により、トランザクションログが破損していても
データファイル上のデータを復旧することができます。

ただし、ダーティーページに関してはデータファイル上に書き込みがされていませんので、このようなデータは
トランザクションログだけに書き込まれており、データファイル上には存在しません。

この辺はチェックポイントの発生タイミングに依存しますので、復旧間隔の設定によってどの程度の
データがデータファイルに書き込まれているかが変わっていきます。

[データファイルだけをアタッチ]

SQL Server 2000 以降では sp_attach_singile_file_db というデータファイルだけをアタッチする
ストアドプロシージャがあります。
ログファイルが破損した状態のデータファイルだけをアタッチしようとしたところこの方法は
うまくいきませんでした。

CREATE DATABASE でアタッチする方法も同様でエラーとなってしまいました。

SQL Server 2005 以降では復旧中になっているデータベースはデタッチできないようになっているので、
間違ってエントリをはずすことはないかとは思いますが。

SQL Server 2000 では sp_attach_single_file_db による、単一のデータファイルによるアタッチしか、
データファイルをアタッチする方法がありませんが、状況によってはデータファイルのアタッチによる
復旧ができる可能性もあるかと思います。
# 今回、私は失敗しましたが・・・。

ログファイルが二重化できないのである程度の復旧となってしまいますので、トランザクションログの構成については
Oracle に優位性があるのは確かだと思います。

ただし、SQL Server ではバックアップ取得時点でなくても途中までは復元できる可能性は残っています。
# DBCC でログを再構築した場合はログチェーンも切れてしまうと思いますので、トランザクションログの
? バックアップ運用をしていても直前までは復元できないと思います。

よい機会だったので、復元のメモ書きとして投稿しておきます。

Written by Masayuki.Ozawa

9月 4th, 2009 at 4:26 pm

Posted in SQL Server

Winodws Server 2008 のハートビート用 NIC のチーミングサポートについて

without comments

Tech・Ed Japan 2009 で Windows Server 2008 のハートビート用 NIC のチーミングサポートについての
話がありましたの調べてみました。

以下の KB に 2008 についての情報が記載されていました。

Network adapter teaming and server clustering

Note In Windows Server 2008 and Windows Server 2008 R2, there are no restrictions that are associated with NIC Teaming and the Failover Clustering feature.
In Windows Server 2008, the new Microsoft Failover Cluster Virtual Adapter is compatible with NIC Teaming and allows it to be used on any network interface in a Failover Cluster.

この KB の日本語のものはよく見ていたのですが、英語版にしか記載がないということに気づいていませんでした。

2008 ではハートビート用 NIC にチーミングを使用した場合の制約はないみたいですね。

Written by Masayuki.Ozawa

9月 4th, 2009 at 6:51 am

Posted in MSCS/WSFC(MSFC)

SCVMM 2008 R2 RC を RTM にアップグレード

with 2 comments

2009/9/4 時点 では SCVMM 2008 R2 RTM がダウンロードできなくなってしまったようですが、
ダウンロード可能なときにイメージを入手できたので RC からのアップグレード手順をまとめてみたいと思います。

以下の順番で作業をします。

  1. Connect から Pre-release Upgrade Tool をダウンロード
  2. Pre-release Upgrade Tool で データベースをアップグレード
  3. SCVMM 2008 R2 RC をアンインストール
  4. SCVMM 2008 R2 RTM をインストール
  5. 各ホストのエージェントを更新

一度、RC をアンインストールする必要があるのですが、SCVMM のデータベースは Pre-release Upgrade Tool で
アップグレードすることにより、継続して使用できるので設定などに関してはそのまま使用することができます。

  1. Connect から Pre-release Upgrade Tool をダウンロード
    Connect から Pre-release Upgrade Tool をダウンロードします。

    System Center Virtual Machine Manager 2008 R2 

    Pre-release Upgrade Toool はひとつの EXE ファイルになります。

  2. Pre-release Upgrade Tool で データベースをアップグレード
    UpgradeVMMR2RC.exe を実行します。

    以下がコマンドのヘルプになります。

    >UpgradeVMMR2RC.exe
    Microsoft System Center Virtual Machine Manager 2008 R2 RC Upgrade Tool
    Use this tool to upgrade your VMM 2008 R2 RC database.
    Usage:
    UpgradeVMMR2RC.exe -server <computername[instancename]>  -database <database>
    Example (named SQL instance):
    UpgradeVMMR2RC.exe -server VMMDB01MICROSOFT$VMM$  -database VirtualManagerDB
    Example (default SQL instance):
    UpgradeVMMR2RC.exe -server VMMDB01  -database VirtualManagerDB

    コマンドラインで指定するサーバーは SQL Server になりますので、SCVMM 用の DB をアップグレード
    しているのだと思います。

    実際の実行結果はこちらになります。

    >UpgradeVMMR2RC.exe -server localhostMICROSOFT$VMM$ -database VirtualManagerDB
    Upgrade Microsoft System Center Virtual Machine Manager 2008 R2 database from RC
    to RTM.
    Open database connection; Begin transaction.
    Upgrading the database schemas …
    Upgrading the stored procedures …
    Commit transaction.
    Upgrade of the database structure completed.
    The upgrade successfully completed!

    DB のアップグレードが実行されているというログが表示されています。

  3. SCVMM 2008 R2 RC をアンインストール
    RC がインストールされた状態で RTM をインストールしようとすると以下のエラーになります。
    image 
    このままでは RTM のインストールができないのでアンインストールを行います。

    私の場合は VMM サーバーと管理コンソールをインストールしていたので以下の 2 つをアンインストールしています。
    セルフサービスポータルをインストールしていた場合はそちらも削除したほうがよいかもしれないですね。
    image 

    [2.0.4258.0] が RC のバージョンのようですね。 

    VMM サーバーのアンインストール時にデータの保持の選択がありますので、ここではデータの保持を選択します。
    DB は継続して使用することができますので。
    image

  4. SCVMM 2008 R2 RTM をインストール
    RC のアンインストールが終わったら RTM をインストールします。
    インストール作業は RC と同じです。

    1 点注意する箇所があるとすると、RC で使用していた DB を Pre-release Upgrade Tool で RTM 用に
    アップグレードしてありますので、DB に関しては既存のものを使用するように設定することぐらいかと。

    image

    WAIK 等のツールは RC のインストール時のものがそのまま使用されて、VMM サーバーだけがインストールされました。

    インストール後のバージョンは [2.0.4271.0] となっています。

  5. 各ホストのエージェントを更新
    インストール直後の状態で各ホスト OS のエージェントのバージョンが古くなっているため、サーバーの状態が
    [要注意] となっています。
    image
    エージェントを更新して各ホストの状態を最新にします。
    エージェントは [ホスト] から対象のホストを選択し、[アクション] の [エージェントの更新] から実行できます。
    image 
    エージェントが更新されるとすべての状態が正常になります。
    image

アップグレードというよりは再インストールに近い作業ですね。

Written by Masayuki.Ozawa

9月 4th, 2009 at 1:58 am

Posted in System Center