先日から、Windows 7 のデフォルトプロファイルのカスタマイズについて調べていました。
Windows 7 ではデフォルトプロファイルのコピーは [Sysprep] を使用して行うのがサポートされる方法となっているのですが、この際に再初期化数について注意する必要がありますので、この内容についてまとめていきたいと思います。
Read the rest of this entry »
Archive for 12月, 2010
Windows 7 の再初期化数について
クラスター環境の SQL Server 2008 R2 のアクティブノードにパッチ適用した際に発生したエラーについて
前回はローリング アップグレードということで、パッシブ ノードからパッチを適用していました。
アクティブ ノードからパッチを適用したらどうなるのだろうと思って試してみました。
SQL Server 2008 R2 にローリング アップグレードでパッチ適用
TechNet フォーラムを見ていたところ SQL Server 2008 R2 のローリングア ップグレードを使用したパッチ適用についての投稿がありました。
そういえば、SQL Server 2008 以降のクラスタ環境ではローリング アップグレードのシナリオが追加されていたなということを思い出し、良い機会だったので試してみました。
# Tech・Ed 2009 のセッションでの話があったということをブログに書いていたのですが試していませんでした…。
技術情報としては以下の情報が参考になります。
# フォーラムに記載されていた技術情報になります。2008 R2 でも同じ手順になります。
SQL Server 2008 フェールオーバー クラスタにローリング更新プログラムおよび Service Pack を適用する方法
今回は使用しないのですが以下のような技術情報もあります。
FIX: Error message when you perform a rolling upgrade in a SQL Server 2008 cluster : "18401, Login failed for user SQLTESTAgentService. Reason: Server is in script upgrade mode. Only administrator can connect at this time.[SQLState 42000]"
SQL Server フェールオーバー クラスター インスタンスをアップグレードする方法 (セットアップ)
第 1 回 Get The Fact セミナーの振り返り その 7
今回は [データベースの整合性確認の負荷] について振り返っていきたいと思います。
前回の振り返りでまとめていたデータベースの整合性確認 (DBCC CHECKDB) ですが、データベースの状態を確認するためには大事になる処理ですが、整合性を確認するためには負荷がかかります。
Exchange の Autodiscover について (DNS で解決)
前回はドメイン環境で SCP を使用して Autodiscover による設定の自動検出を行いました。
今回は SCP が使用できない場合の Autodiscover についてまとめていきたいと思います。
Exchange の Autodiscover について (ドメイン環境で SCP)
昨日から、Exchange の Autodiscover (自動検出サービス) について少し調べていました。
Autodiscover ですが、以下の情報がとても参考になります。
Exchange Server 2007 の Autodiscover で自動構成できない!! を回避するために
この情報をもとに、Autodiscover について自分なりにまとめてみたいと思います。
Autodiscover の動作は、ドメインに参加していてドメインユーザーでログインしている場合と、ワークグループ環境 (ドメインに参加していてローカルユーザーを使用している場合も同じ) の場合で挙動が変わりますのでこの 2 パターンでまとめていきたいと思います。
今回は Exchange 2010 と Outlook 2010 の組み合わせで検証しています。
# 基本的な考えは Exchange 2007/Outlook 2007 でも同じになるはずです。
Outlook 2007 で Exchange 2010 のアーカイブを表示
Exchange 2010 には個人用アーカイブ (Personal Archives) という機能が追加されました。
今まで、メールのアーカイブはローカルに PST ファイルを作成して実施してましたが、Exchange 2010 ではメールボックスとは別にサーバー上にアーカイブ用のメールボックスを持つ (個人用アーカイブを作る) ことができ、そのメールボックスにメールをアーカイブすることが可能になりました。
# RTM では、アーカイブのメールボックスはユーザーのメールボックスと同じデータベース内にしか作れませんでしたが、SP1 から別のデータベースを指定できるようになりました。
ワークグループ環境の Outlook で OAB がダウンロードできない
今日は久しぶりに Exchange 2010 を触っていました。
ちょっとクライアント側で調べたいことがあったので、Windows 7 + Outlook 2010 の環境を作ってテストしていました。
メールの送受信はできていたのですが、オフラインアドレス帳 (Offiline Address Book : OAB) をダウンロードしようとしたところ以下のエラーが。
クラスタ環境の SQL Server 2005 に SP4 をインストール
先日、SQL Server 2005 SP4 が提供されました。
Microsoft SQL Server 2005 Service Pack 4 RTM
Windows Server 2008 のクラスタ環境にインストールした SQL Server 2005 にサービスパックを適用する場合には注意点がありますのでまとめてみたいと思います。
# 2008 以外でも発生するかもしれません。(2003 では発生しなかった気もするのですが)
SQL Server 2005 のメインストリームサポート終了日が [2011/04/12] と半年を切っており最新のサービスパック適用の機会があるかもしれないので軽く書いておこうかと。
今回は SP4 を対象としてまとめていますが、SP1 ~ SP3 , Cumulative Update に関しても同様の手順が必要になります。
# CU に関しては、発生するかは更新内容によって変わると思うのですが。
クラスタ環境で SQL Server 2005 のサービスパックをインストールする場合は、SQL Server のリソースを保持しているノードでサービスパックのインストールを実行します。
SQL Server のリソースを保持していないノードでサービスパックのインストールを実行しても、[MSSQLSERVER] (SQL Server ノーサービスコンポーネント) は選択をすることができません。
クラスタ環境の SQL Server 2005 でサービスパックをインストールすると [データベース サービス] のインストールで失敗する場合があります。
インストールの失敗ですが以下の技術情報が該当します。
An error message is logged in the Summary.txt file when a SQL Server 2005 service pack, cumulative update or cluster hotfix installation fails: "The Transaction Manager is not available"
SQL Server 2005 のサービスパックのインストールログですが以下のディレクトリに出力されます。
[C:Program FilesMicrosoft SQL Server90Setup BootstrapLOGHotfix]
このディレクトリの中に、[Summary.txt] がありますので、このファイルの内容を確認してみます。
Product Installation Status |
データベース サービスで [正常に修正プログラムが適用されたパッシブ ノードはありません] のエラーが出力されています。
このログは [アクティブ ノード] (SQL Server のリソースを持っているノード) のログになりますので、パッシブ ノードでもログを確認してみたいと思います。
# ログはアクティブ ノードと同じディレクトリに出力されています。
Product Installation Status |
今回の現象ですが、パッシブ ノードで [データベース サービス] のサービスパック適用に失敗しているのではなく、[クライアント コンポーネント] に対してのサービスパック適用で失敗しています。
この現象ですが、[クラスタの MSDTC のリソースをクライアント コンポーネントの適用が実行されているノードが所有していない] と発生します。
DTC と SQL Server のリソースを [2008-CLS-01] というサーバーで所有させていました。
この状態でサービスパックを適用したため今回の現象が発生していました。
■Windows Server 2008 のクラスタ環境に SQL Server 2005 のサービスパックを適用
ここからが本題で適用するための手順になります。
[2008-CLS-01] でサービスパックのインストーラーを起動するため、SQL Server のリソースは [2008-CLS-01] に配置しています。
DTC のリソースは [2008-CLS-02] (SQL Server から見てパッシブ となっているノード) に配置しています。
この状態でサービスパックのインストーラーを実行します。
- [次へ] をクリックします。
- [同意する] を選択して、[次へ] をクリックします。
- 適応するコンポーネントを選択して、[次へ] をクリックします。
- リモート ユーザーのアカウント情報を入力し、[次へ] をクリックします。
パッシブ ノード側ではここで指定したアカウントを使用してサービスパックの適用が実施されます。 - [次へ] をクリックします。
- [次へ] をクリックします。
- [インストール] をクリックして、インストールを開始します。
インストールをクリックするとパッシブ ノードのタスク スケジューラに [SqlNodeInstall] といタスクが作成され、パッシブ ノードでサービスパックのインストールが開始されます。
このタスクを使用して、インストーラー実行時にパッシブノードの [C:UpdateTemp] にコピーされたサービスパックのプログラムが実行されます。
パッシブ ノードのタスクマネージャーを確認すると [msiexec.exe] や [hotfix.exe] が起動されていることが確認できます。
インストールを開始してしばらくしているとパッシブ ノードで以下のダイアログが表示されます。
# パッシブ ノードにサービスパックのインストール時に指定したアカウントでログオンしておく必要があります。
Windows Server 2008 + SQL Server 2005 の場合、VS 2005 がプログラム互換性アシスタントの警告対象となります。
DTC をパッシブ ノードで実行している場合は、このダイアログが表示できるのですが、アクティブ ノードで DTC を実行している場合はこのダイアログが表示されません。
そのため、クライアント コンポーネントのアップデートができずにエラーとなってしまうようです。
クライアント コンポーネントはアクティブ / パッシブのノード両方でインストールする必要があります。
そのため、アクティブ ノードでクライアントコンポーネントのアップデートが実行される際には、DTC のリソースはアクティブ ノードで実行しておく必要があります。
上記のダイアログがパッシブ ノードで表示されたら、クラスターの管理コンソールを開き、リソースの配置を以下の用に変更しておきます。
# DTC のリソースを [2008-CLS-02] → [2008-CLS-01] に移動しました。
DTC の配置が終わったら、[プログラムを実行する] をクリックします。
# アクティブ ノードでクライアントコンポーネントの適用が実行される前までに DTC のリソースを移動しておけば問題ありません。
パッシブ ノードでインストールが終了すると、アクティブ ノードでインストールがされます。
アクティブ ノードでも [クライアント コンポーネント] のインストールが実行されるタイミングで、プログラム互換性アシスタントのダイアログが表示されますので、[プログラムを実行する] をクリックします。
# アクティブ ノードで DTC のリソースが実行されていないと今度はアクティブ ノードでインストールが失敗します。
この手順でインストールをするとサービスパックの適用が正常に完了します。
SQL Server 2005 のサービスパックをクラスタ環境に適用する場合はクラスタの DTC リソースの配置状況に注意する必要があります。
この現象ですが、[クライアント コンポーネント] の更新が入らない場合は発生しないので、CU の適用時にはクライアントコンポーネントが更新対象として含まれていなければ失敗はしないと思います。
第 1 回 Get The Fact セミナーの振り返り その 6
今回は [データベースの整合性確認] について振り返っていきたいと思います。
[メンテナンス プラン ウィザード] では、 [データベースの整合性確認] のメンテナンス タスクを作成することが可能です。
このタスクを実行するとデータベースの整合性をチェックすることができます。
セミナーの中では、バックアップの取得前等に実行をすることでデータベースに問題が無いかを確認しバックアップを取得することが可能というようなお話がありました。
今回は、この整合性確認についてまとめていきたいと思います。
■データベースの整合性確認で実行される内容
まずはデータベースの整合性確認のタスクで実行される内容について確認していきたいと思います。
作成したデータベースの整合性確認のタスクで実行される T-SQL を確認してみます。
データベースの整合性確認のタスクでは、実行対象として指定したデータベースに対して [DBCC CHECKDB] が実行されます。
# [インデックスを含める] を外すと [NOINDEX] オプションを指定して実行されます。
以下は、BOL の DBCC CHECKDB の記載内容の引用になります。
次の操作を実行し、指定したデータベース内のすべてのオブジェクトの論理的および物理的な整合性をチェックします。
- データベースに対して DBCC CHECKALLOC を実行。
- データベース内にあるすべてのテーブルとビューに対して DBCC CHECKTABLE を実行。
- データベースに対して DBCC CHECKCATALOG を実行。
- データベース内にあるすべてのインデックス付きビューの内容を検証。
- FILESTREAM を使用して varbinary(max) データをファイル システムに格納する場合のテーブルのメタデータとファイル システムのディレクトリおよびファイルの間のリンクレベルの一貫性を検証。
- データベースの Service Broker データを検証。
DBCC CHECKDB では、上記の処理を実行してデータベースの整合性が取れているかを確認する処理になります。
■整合性確認を実施しないとどうなるか
データベースの整合性確認を行う事でどのようなことが分かるか、簡単に試してみたいと思います。
今回は、バイナリエディタでデータファイル (mdf) を開き、一部のデータを書き換え、データの内容とページのチェックサムが一致しないようにしてみました。
データを書き換える前のテーブルの全件を取得した情報がこちらになります。
SQL Server 2008 以降であれば、データがどのページに格納されているかは [sys.fn_PhysLocFormatter(%%physloc%%)] を使用することで確認することができます。
# この関数は、Undocument の関数です。
上のデータは、以下のクエリを実行して取得しています。
SELECT |
SQL Server のページにはチェックサムがあり、データの内容を元に計算したチェックサムとデータの内容が一致しているかを確認することで、ページが破損しているかを検出する機能がありますのでページに一貫性が無いとエラーとして検出することができます。
# データベースオプションで [CHECKSUM] / [TORN_PAGE_DETECTION] / [NONE] のいずれかを設定することが可能です。([TORN_PAGE_DETECTION] は下位互換となっていますが。)
今回はバイナリエディタでデータベースのファイルを開いて、 (1:114:0) のページを壊してみました。
ページを壊した後に、データを全件取得すると以下のデータまでは取得できるのですが、 (1:114:0) のデータを読み込もうとした際にエラーが発生します。
メッセージ 824、レベル 24、状態 2、行 1 |
(1:114) という情報が表示されていますので、ファイル ID 1 (mdf ファイル) の 114 ページに一貫性のエラー (チェックサムとデータが不整合) が発生していることが確認できます。
今回、私が壊したページ番号と一致しますね。
破損ページの操作をした場合、イベント ビューアーのアプリケーションにも同様の情報が出力されますので、監視ソフト等でログ監視をしているのであれば、エラーを検知することもできます。
今回はデータを全件読み込みしたので破損ページも読み込まれエラーが発生しましたが、破損したページにアクセスをしなければ正常にデータを読み込むことができます。
# Col = 4 のデータを読もうとするとエラーになってしまうので飛ばしています。(先行読み込みの可能性が)
破損したページを操作しないとエラーにはなりませんので、データベースに異常があるかは分かりません。
DBCC CHECKDB を定期的に実行することで障害により発生した潜在的に潜んでいるデータベースの異常をチェックすることが可能です。
[DBCC CHECKDB(N’TEST’)] を実行して、今回整合性のエラーが発生している [TEST] データベースでデータベースのチェックをしてみます。
‘TEST’ の DBCC 結果。 |
DBCC CHECKDB を実行することで、データベースの状態をチェックしてくれますので、破損している領域を操作しなくても異常があるかどうかの確認をしてくれます。
イベントビューアーと SQL Server のログにも結果の概要が出力されますので、後で結果を再確認することも可能です。
SQL Server のダンプのテキストも出力されています。
[msdb..suspect_pages] を SELECT することで直近の情報を取得することもできます。
DBCC CHECKDB をバックアップ実行前に実施する理由ですが、[障害が発生しているデータベースのバックアップは障害が発生した状態] となるからです。
障害が発生していない状態のデータベースのバックアップがないと破損している領域を修復することができません。
# SQL Server 2008 以降のデータベースミラーリングであれば、破損ページを読み込んだ際にミラー側から修復することも可能ですが。
そのため、バックアップを取得する前にデータベース自体に異常が無いかを確認して、その後にバックアップを取ることが推奨されます。
セミナーの中で質問 / 回答があったのですが、DBCC CHECKDB によるデータベースの整合性確認はデータベースのサイズが大きいとかなり負荷がかかります。
そのため、バックアップのたびに毎回実行するのが難しいかもしれませんね。
次の投稿では [データベースの整合性確認の負荷] についてまとめてみたいと思います。