- [T5-307] Hyper-V 2.0 のバックアップ – ベスト プラクティス –
– Hyper-V を構成するファイル
バックアップの基礎知識のため、ファイルの構成を理解する
構成情報 (xml)
仮想ハードディスク (vhd)
メモリ情報 (bin)
状態情報 (vsv)
で構成される。
メモリ情報と状態情報は仮想マシンの起動時に作成される。これらのファイルは保存時に使用している。
# メモリ情報は起動時は空だが、割り当てメモリのサイズは作成される。領域の予約のため。
構成ファイルの ID は仮想マシンの内部 ID となる。
容量可変ディスクの初期サイズは 1MB
差分ディスクは最も効率的なディスクの利用だがパフォーマンスが低い。
パススルーディスク以外は 2TB 以上のディスクは作成できない。
スナップショットを取得すると xml / bin / vvsv はコピーされ、VHD は avhd として差分コピーとなる。
# BIN と VSV は復帰のため、情報が書き込まれている。
スナップショットはバックアップではない。
initialStore.xml で Hyper-V のアクセス権限ファイル。
# azman で編集できる。メモ帳でも可。
このファイルが壊れると Hyper-V が動かなくなるので、バックアップを取得する。
SCVMM エージェント をインストールしていると、別のファイル (Hyper-VAuthstore.xml) で管理している。
– Hyper-V のバックアップ手法
ファイルのコピー
最も単純なバックアップ
バックアップ時には仮想マシンの停止が必須。
VHD と InitialStore.xml のみコピー対象。
パススルーはバックアップできない。
回復時は仮想マシンを新規作成する。
# 仮想マシンの ID は変更される。
スナップショットを使っていると VHD が古い可能性がある。
# 最新の AVHD に現在の情報が書き込まれているため。
スナップショットを使っている場合は、コピー前に VHD に最新の状態をマージした状態にする。
PowerShell Management Library for Hyper-V を利用すると楽。
# codeplex で公開されている。これ以外のコマンド操作の方法は WMI をしようする。ちょっと厳しいですね。
プロファイルに設定しておけば自動的に読み込むことができる。
エクスポートは停止、または保存中の状態で実行可能。オフラインが必須。
エクスポートしても元のゲスト OS は削除されない。
スナップショットも含む。
パススルーを含むとエクスポート不可。
差分ディスクのバックアップは親ディスクも含む。
InitialStore.xml は含まれない。
2.0 で機能強化され、再インポートとプロセッサバージョンの異なる物理コンピュータへ移行できる。
# CPU のバージョンが違うとレジスタの情報が違うため、1.0 だと失敗していた。
Windows Server バックアップでもバックアップ可能
ボリューム単位のバックアップなので、ゲスト OS が存在するボリューム全体を取得する。
ゲスト OS 単位の復元はできない。Hyper-V というアプリケーション全体を復元する。
VSS でオンライン状態のバックアップが可能。
VSS のライタは vssadmin list writers で確認。
InitialStore.xml とスナップショットを含むゲスト OS のすべてのフィルを保存できる。
wbadmin または PowerShell コマンドレットでコマンドから実行可能
アプリケーション単位の復元をするためには事前にレジストリの変更が必要。
# バックアップの前に変更しておく
CSV のバックアップは不可。
# 取得できたように見えるがバックアップデータが空になっている。
VSS 未対応 のゲスト OS が含まれている、統合サービスのバックアップ機能が無効になっている、
FAT / ダイナミックディスクが含まれるオンラインバックアップできない。
トランザクション (AD / Exchange / SQL Server) 等のゲスト OS ではアプリケーションの
整合性が取れないためゲスト OS 上でバックアップを取得する。
GUI のバックアップ機能が強化されている。
ホストの台数が少ないとこれらのバックアップでも対応できるが、統合 / 運用管理やノンストップでの
バックアップについて課題が残る。
– Data Protection Manager 2007 SP1 を使用した Hyper-V のバックアップ
Hyper-V 2.0 に対応している
DPM であればテープに取得できる。
各サーバーにエージェントをインストールし、DPM サーバーでバックアップをする。
Hyper-V はホスト OS にエージェントをインストールすると、ゲスト OS のバックアップが取得できる。
# ゲストにエージェントをインストールするパターンもある。
DPM は DPM 2007 管理者コンソールで管理するんですね。まだ検証していないので今回初めて見ました。
保護グループを作成、利用可能なメンバから取得対象を選択 (エージェントが取得他使用を返す)、
データ保護方法、保存期間を選択、保護グループのメンバのディスクサイズを設定、スケジュールを設定、
圧縮の設定をしてバックアップジョブを作成する。
Hyper-V は DPM SP1 で対応。SP1 には Feature Pack が含まれる。
仮想マシン単位のバックアップ / 復元が可能。
DPM でも CSV のバックアップは不可。
現状、CSV のゲスト OS のバックアップはインポート / エクスポート。
DPM v3 (次期バージョン) で CSV に対応される。
ファイル単位の復元をしたい場合 / トランザクションを処理している ゲスト OS はゲストに
エージェントをインストールし、ゲストレベルバックアップを取得する。
# ホスト OS のバックアップ取得と組み合わせることができる。
最初に全ブロックを単純バックアップする (全ブロックをレプリカにコピー)。
次のバックアップでは変更されたブロックを送り、レプリカを更新。
更新対象となったブロックは回復ポイントに保存される。
# 押し出されたブロックが回復ポイントに移動される。
回復はレプリカと回復ポイントを使用して復元している。
OpsMgr 用の管理パックがあるので連携ができる。
SP1 からローカルリソース保護で Hyper-V のホスト OS 上にインストールできる。
# 小規模環境で統合した環境を作成できる。
ただし、機能を有効にするには PowrShell で有効化する必要がある。
パススルーディスクは DPM であればバックアップ可能。
ホストとゲストのバックアップを同時に実行しない。
# VSS Writer の競合が発生し、ロックが発生することもある。
Hyper-V の設定と仮想ネットワークマネージャの設定は個別に管理。
# レジストリに書き込まれているので、ドキュメントとして残しておくようにする。
現在、手順が確立されていない。
- [T4-302] SQL Server 旧バージョンからの移行
2000 / 2005 からの移行シナリオ。
– SQL Server 2008 へ移行するメリット
ストレージ使用量の削減。
行圧縮 / ページ圧縮
圧縮により、データの通信量が減るため、クエリパフォーマンスが向上する。
# CPU の使用量とのトレードオフですよね。
バックアップ圧縮。
バックアップ時間だけでなく、復元時間も短縮できる。
# 圧縮を解除して復元するときのパフォーマンスってどうなんでしょう？？あまり気したことがなかったな。
データベースの暗号化。
2008 の透過的データ暗号化。
# 暗号化したデータベースが使われている場合のサーバー初期化後の復旧手順をまとめないとな～
SSMS
2000 移行のバーっジョンを統合管理できる。
リソースガバナ
# リソースガバナのデモでよく使われている Resource Governor Loads はダウンロードできないのかな？？
CPU の割合の最大値 100 は各リソースプールで CPU を等分に使用する。
動的に割り当てを変更できる。制限をかけても余っている場合は使用率を超えて効率よく利用する。
– 旧バージョンからの移行の全体像
移行前にパフォーマンスの確認と使えなく (われなく) なる機能の確認。
アップグレードアドバイザで確認。
アップグレードまたはマイグレーション。
監視、機能 / 性能試験。
アップグレードアドバイザ
2009 年 4 月の Feature Pack が提供されている。
Windows インストーラ 4.5 が必要。
# リモートからも実行できるので、サーバーにインストールする必要はありません。
DTS と SSIS は別項目として分析対象がある。
DTS はサーバーのものと DTS パッケージのファイルのどちらも分析できる。
アップグレードとマイグレーション
アップグレードはインプレースアップグレード
# インスタンスのアップグレードだけすることってあまりないですよね…。
マイグレーションは新サーバーを用意し、データベースを移行する。
アップグレードはインストールメディアから実行する。
– アップグレード
ローリングアップグレード
高可用性構成でアップグレードするときに使用する。
ダウンタイムを小さくしながらアップグレード
Service Pack や修正プログラムの適用も対応予定。
2008 でクラスタのローリングアップグレードが可能となった。
# ローリングアップグレードはフェールオーバー中だけがダウンタイムとなるそうですが、
システム DB はどのタイミングで更新されるんでしょう？？
デタッチ / アタッチ、バックアップ / リストア 、データベースコピーウィザードでユーザー DB の移行ができる。
デタッチ / アタッチが一番単純であるがオフライン必須。
# ミラーリング等の高可用性の設定をしているとデタッチ / アタッチの移行ができない。
デタッチするとダーティーページがデータファイルに反映されたはずです。
メモリではなくログから適用しているんでしたっけ？？あとで調べよう。
ログインを移行できるのはデータベースコピーウィザード。
# ユーザーの移行タスクがありますよね。
システムデータベースの移行
データベースは直接移行できない。
サーバーの構成 / ログイン / ジョブの移行がポイント
構成は sp_configure または 2008 のファセットで移行する。
SQL Server エージェントの内容はスクリプトに出力して移行するとシンプルだと思います。
ログインの移行は孤立ユーザーに注意
# ログインとユーザーのマッピングが外れているユーザーですね。
定番の sp_change_users_login で変更します。
sp_change_users_login @action=’Report’ で孤立ユーザーの検出
ジョブは移行先のサーバーで作成する。
サービスアカウントとジョブの実行アカウントに注意。
# ジョブの移行タスクかジョブをスクリプトに出力して移行することもできますよね。
– マイグレーション
DTS は SSIS に変わり、内部構造が変更されている。
DTS パッケージ実行タスクは 64 ビット環境でランタイムがサポートされていない。
# Windows Server 2008 R2 は 64 ビットだけなので注意しないと。
パッケージ移行ウィザードで SSIS パッケージに変換するのがよいのかな～。
DTS 2000 ランタイムで x64 環境で WOW64 で実行させることもできる。
# 2008 Feature Pack に含まれる。ただし、廃止される機能である。
2000 DTS デザイナコンポーネントは 2005 の Feature Pack
# SSMS で DTS を変更する場合には必要となる。
SSIS の移行
SSIS パッケージアップグレードウィザードがお勧め。
2005 のパッケージを 2008 の dtexec で実行すると、一時的に 2008 で実行可能な形に変換されるが、
実行後に 2005 の形式に戻る。
SSIS はインスタンス毎に別れていない。サーバーに一つ。
# SSIS はクラスタリソースには入っていなかったですよね。汎用サービスとして登録かな～。
SSAS の移行
2000 では移行ウィザードによる移行。
# バックアップ / リストアによる移行は不可。
# Migrationwizard を実行 (SSAS / OLAP といった文字は含まれない。)
2000 の SSAS を移行するためのツール。
DTS の SSAS 系のタスクは移行できないので、新規作成。
Excel のピボットテーブルは再配置の必要がある。
2005 ではバックアップ / リストアによる移行が可能。
SSRS の移行
2000 / 2005 で共通の移行方法。
データベースを移行するのがお勧め。
# 2000～2008 ですべて互換性がある。
暗号化キーの移行が必要となる。
# レポーティングサービスの接続情報の保護に使用されている。
レポーティングサービスの実行アカウントの GUID に基づいて生成されている。
特定のレポートのみを移行する場合はデータベースの移行ではなく、BIDS やレポートマネージャで個別に移行する。
SSRS の Web サーバーについての話がなかったのが残念でした…。
- [T3-306] Office SharePoint Server 2007 for Internet sites サイト構築手法
for Internet Site というライセンスがある。
6 つの機能領域
コラボレーション : 情報共有
ポータル : 情報の集約とターゲッティング (どのようなプロファイルを持っているユーザーに見せるか)
検索 : 検索
# 上 3 つがインフラストラクチャ
コンテンツ管理 : ドキュメント管理、ドキュメント管理はポータルとは違う。
ビジネスプロセス
BI
# 上 3 つがソリューション。3rd パーティーのコンポーネント利用もある。
重要な設計事項
セキュリティ
認証方式
アクセス URL
外部ネットワーク向けの設定シート
外部と内部で異なった認証方式を設定。
既存の Web アプリケーションの拡張を使って、入り口だけを変更する。
代替アクセスマッピングの設定。
# 領域をインターネットにする。リバースプロキシがある場合も代替アクセスマッピングを使う。
拡張された Web アプリケーションは Web アプリケーションの一覧には表示されず、
代替アクセスマッピングに表示される。
イントラネットではパブリック URL と内部 URL のセットが使われている。
内部 URL はプロキシを挟んでいるときに SharePoint が認識するための URL
フォーム認証
SharePoint は .NET の認証のパイプラインをそのまま使っている。
SSL でセキュリティを確保する。
メンバーシップ : ユーザー
ロール : グループ
aspnet_regsql でフォーム認証用 DB を作成。既定だと ASNETDB という名称で作成される。
# セキュリティの観点から変更したほうがよい。
web.config の設定変更が必要。
接続文字列を設定 → プロバイダを設定 → .NET ユーザー → .NET の役割 → 役割を設定 →
サイトコレクションの権限を設定
サービスアカウントにフォーム認証用の DB のアクセス権を設定する。(db_owner)
# db_owner より低い権限で動かせないかな？？
小規模ファームからスタート可能
情報構造はサイトとサブサイト構造を中心に考えていくと設計の手助けになる。
管理パスを使った階層化
Access 2007 は SharePoint のフォーム / リストと連携するマクロが記述できる。
MS の MOSS の製品サイトは MOSS で動いている。
情報構造に基づいて DB を用意
フィーチャーは管理者が展開可能なように Web Solution Package 化する (WSP ファイル)
ネットワーク境界には Office SharePoint Server for Internet sites を利用。
Forefront の SharePoint でウイルス対策。
匿名認証は Web アプリケーションだけでなく、サイトの設定でも設定する
コンテンツ展開を使ってステージングから本番にコンテンツを公開する。
# イントラネット用の内容をインターネットに公開するときに使える。
2008 の IIS だとフォーム認証の管理がしやすい。
ShrePoint の RIA の書籍が 10 月に Microsoft プレスから発売される。
- [T4-301] SQL Server 2008 運用管理再入門
自習書シリーズは現在、新コンテンツを作成中。
– 多い質問
急に担当になってしまったがなにをすればよいか。
マシンの妥当性。
定期メンテナンスは必要なのか？
データベースは生き物。
断片化する。
トラブルの未然防止のため、リソース使用状況をチェック。
SSMS のレポートとパフォーマンスデータコレクションが役に立つ。
– SSMS のレポート機能
意外と知らないユーザーさんが多い。
2005 から提供された機能
サーバーレベルのレポートとデータベースレベルのレポートがある。
– サーバーダッシュボードレポート
SQL Server の変更されている構成がわかる (既定以外の変更)
– スキーマ変更の履歴レポート
インデックスの変更履歴がわかる
– ディスク使用量レポート
実際の使用量がわかる。
自動拡張の履歴が確認できる。
# デフォルトトレースから取得している。20 MB の 5 ファイルでローテーションしているので注意
レポートは Excel へエクスポートすることができる。
自動拡張が発生するとレスポンスが低下する。
デフォルトトレースはトレースファイルなのでプロファイラと fn_trace_getinfo(default) で情報を確認できる。
イベント ID 92 データの自動拡張 / 93 ログの自動拡張
– パーティションごとのディスク使用量
テーブルとインデックスの使用サイズを確認できる。
– インデックスの物理統計レポート
インデックスの断片化状況を確認できる。
再構成か再構築の推奨操作を表示してくれる。
30% 以上なら再構築 / 未満なら再構成となる。
レポートを表示するときにプロファイラを実行しておくとどの情報を取得しているかがわかる。
ログと tempdb のサイズ確認も忘れずに。
# tempdb を忘れているケースが多い。
プレゼンテーションに載っている値はスピーカーの経験則。
– パフォーマンスデータコレクション
SQL Server の動作状況の自動収集。
SSMS のレポートを大きく拡張した機能。
2008 以前のバージョンではシステムモニタを利用
システムデータコレクションセットで取得されたデータを基にレポートを作成。
# そういえばスパークライン的な表示が 2008 ですでに使われていたんですよね。
過去にさかのぼって情報を閲覧できる。
# SQL Server が稼働している期間内で。
パフォーマンスモニタの情報をシステムデータコレクションとして取得している。
# プロパティで確認できる。
トラブルはピークタイムに起きる。
ピークタイムを見つけることが大事。バッチ数 / ログイン数から把握。
ピークタイムに耐えられる H/W スペックを考慮する。
ディスクの高負荷はメモリ不足が原因となることも。
キャッシュのヒット状況を確認する。
Database Pages : データバッファキャッシュのサイズ
Chache Pages : プロシージャキャッシュ
Workspace メモリ : 一時作業領域
インデックスとデータの両方が載るメモリを確保
インデックスとデータの両方がメモリに載らない場合は、インデックスがメモリに載り、インデックス Seek が
行われるようにクエリを設計するｌ
パフォーマンスデータコレクションの取得カウンタはカスタマイズできる。
# データコレクションセットを新規に作成する。
メモリ関連を細かく取得したい場合はカスタマイズする。
SSMS 2008 のカスタムレポートは 2005 のレポートデザイナで作成する必要がある。
– ディスクが高負荷な場合
待ち事象を確認する。
排他ラッチは書き込み時に発生することが多い。断片化の可能性がある。
共有ラッチは読み取り時に発生することが多い。メモリ不足の可能性がある。
WRITE LOG はログ書き込み。
RAID 5 はパリティ生成のため、書き込みにオーバーヘッドがある。
自動拡張の抑制と、クエリ / インデックスチューニング。(アプリケーションの見直しも)
クエリの統計レポートで実行時間の長いクエリがわかる。ただし、10 件しか表示されない。
10 件以上は DMV から取得する。
– CPU が高負荷な場合
HT はオフにする。パラレルクエリとの相性が悪い。
MAXDOP で調整する。クエリ単位でも可能。
結合やグルーピングは CPU 負荷が高い。
– トラブルの未然防止
ピークタイムの理解が大事。
CPU / メモリ / ディスクキューを確認。
ロックとデッドロックにも注意が必要。
現在のマシンスペックの妥当性と現在の使用状況から、将来のマシンスペックの指針がわかる。
システムモニタでも取得できるが、パフォーマンスデータコレクションはレポートが作成できる。
データコレクションセットの取得中は 5 ～ 10 % の負荷増。
負荷が気になる場合は、クエリ関係の情報取得を停止する。
データベースのサイズ管理と断片化チェックは定期的に実行する。
パフォーマンスデータコレクションで、マシンスペックの妥当性を確認。
- [T4-401] SQL Server トラブルシューティング
Tech Ed Japan 2009 最後の参加セッションです。
– データベース破損
破損状況の確認
修復方法の検討
修復下場合は、修復されていることを確認する。
SQL Server のエラーログを確認する。
# 再起動単位に作成され 7 世代分ある。
DBCC CHECKDB でデータベース全体をチェック
データベースにアクセスできない場合は ALTER DATABASE SET EMERGENCY。
エマージェンシーモード。読み取り専用。
エラー個所はどこか。
クラスタ化インデックス、ヒープ、LOB
Critical System Tables (メタデータ) / Critical Pages (ルートページ / ヘッダーページ)
msdb.dbo.suspect_pages で破損ページがわかる。
DBCC CHECKDB で最小修復レベルがわかる。
2005 移行では、REPAIR_FIRST はない。
# 実行できるが、内部的には REPAIR_REBUILD が実行されている。
バックアップがあるかないか
リストアにかかる時間は。
DBCC CHECKDB にかかる時間。(チェック、修復)
# 壊れる前に確認しておく。
ページのみ / ファイルのみの復元も検討
フルデータベースバックアップ復元後に復元が必要なトランザクションログの数。
REPAIR_ALLOW_DATA_LOSS 時のデータ損失状況は。
ログ末尾のバックアップはトランザクションログが壊れていなければ取得できる。
ログ末尾のバックアップは復旧モデルがシンプル意外。
ログ末尾のバックアップは WITH NO_TRUNCATE
DBCC CHECKDB を使用した修復はシングルユーザーモードにする。
REPAIR_ALLOW_DATA_LOSS の復旧では対象のページごとざっくり切る。
修復後は再度 DBCC CHECKDB で確認。
整合性確認のため、DBCC CHECKCONSTRAINTS。
# 復旧時にページをざっくり切った場合に整合性が保てなくなっている可能性がある。
修復後はマルチユーザーモード
トランザクションログファイル破損
エマージェンシーモードで REPAIR_ALLOW を実行するとトランザクションログファイルが再作成される。
# 2000 では REBUILD LOG でログを再作成できたが、2005 以降はない。
Critical System Tables、メタデータ、Allocation Pages のエラーは DBCC CHECKDB で修復できない。
Data purity エラー (2008 からのエラー)
日付の範囲外などの本来入らないはずの値のエラー(列内の値のエラー)
UPDATE を手動で実行し、データを適切な値に修正する。
ハードウェアエラー
ディスク自体が怪しい場合は、修復中に新たな破損が発生する可能性がある。
破損したデータベースをバックアップして、最悪その時点まで戻せる状態にする。
バックアップが重要。
バックアップの取得間隔、保存期間、保存メディア、保存場所
# データベースと同じディスク上に取得すると危険。ファイルの誤削除に気をつける
復旧モデルの確認。どの段階まで戻すのか。
バックアップしたファイルの論理整合性の確認
# 破損したデータベースのバックアップとなっていないか。破損したデータベースをバックアップしても破損している。
復元手順が確立されているか。
– バックアップ / リストア
T-SQL でバックアップ
バックアップアプリケーションでバックアップ
# VSS / VDI (Virtual Device Interface) これは API / VDI Snapshot これはハードウェアの機能
T-SQL のバックアップは MFT 形式 (Microsoft Backup Format)
VDI Snapshot / VSS
バックアップ要求があると I/O freeze で SQL Server が I/O を停止する。
バックアップステートメントのエラーは SQL Server のエラーログに出力される。
VSS / VDI のエラーはイベントログ
# 7.0 / 2000 は vdi.log に書かれている。
バックアップの一般的な問題
トランザクションログが切り捨てられない。
# アクティブなトランザクションがある。
トランザクションレプリケーション / ミラーリングで未連携のデータがある
OPENTRAN で確認すればいいのかな？？
VSS / VDI のバックアップで一般的な問題
I/O Freeze の時間が長い
# SQLServer が ACID プロパティを書き込めないのでコミットが完了できない
バックアップアプリケーション側の調査が必要
ワーカースレッドが不足する。
# 一つのデータベースを取得するのにワーカースレッドは 5 は必要となる。
2005 以降はワーカースレッドが自動チューニングにより CPU とビット数によって決められるので、
足りなくなる可能性があるので手動で調整する。
– デッドロック
メッセージ 1205 が返ってくる。
リソース名はロック / スレッド / 通信バッファ / 一般待機可能オブジェクト。
# ロック以外でもデッドロックが検出されるんですね。
デッドロックとブロッキングは違う。デッドロックは SQL Server が加入し、強制的に一方のトランザクションを終了
サイクルデッドロック
たすき掛けのデッドロック。
# よく説明のあるデッドロック
同じ行にアクセスしていなくても発生する。
更新時にフルスキャンで全件走査しながら更新していくと発生する。
変換デッドロック
同一行に複数トランザクションで共有ロック。
同一行に対して複数トランザクションで更新。
# 両方のトランザクション S → X に変換しようとして発生。
通信バッファのデッドロック並列クエリが影響している。
並列クエリでスレッド間でやり取りしているものが通信バッファといわれる。
絵で丸になっているのが通信バッファ。
通信バッファの中にはデータが入っている。
# 白い状態が空。右のパイプでデータを渡している。
並列クエリのスレッドはあるタイミングまで互いを意識していない。
MAXDOP で回避することもできる。
# 並列実行されなくなるのでパフォーマンスが低下する可能性がある。
スレッドのデッドロック
スレッドプールがある。処理 (SELECT / UPDATE 等) をするためにはスレッドプールからスレッドが必要となる。
ブロッキング等で処理が停止しているとスレッドプールにスレッドを返さない。（SELECT でも)
SELECT が UPDATE の COMMIT 待ちになっているときに COMMIT をするためのスレッドが
スレッドプールで枯渇している場合に発生する。
ワーカースレッドを手動で小さくすると試すことができる。
デッドロックの調査
トレースフラグ 1205 / 1222
SQL Trace の Deadlock / Graph / Chain
拡張イベント (2008 から)
System_health セッションを確認、デフォルトで有効になっている。
リングバッファのため、古いデータは時間が経過すると消されてしまう。
SQL トレースで実行プランを確認
# トレースで前後のトランザクションを確認する。
キャッシュに残っていればキャッシュから確認することもできる。
一般的な原因
長いトランザクション
Range Scan / Full scan
異なるデータ型同士の比較。データ型にも優先度がある。
優先度によっては、比較対象の項目ではなく、実データの列が変換されることがある。
NUMERIC / DECIMAL の比較は 10.0 / 10. のようにドットつきで検索しないと暗黙の型変換がかかる。
# 10 だと int型になる。
COM+ のトランザクション分離レベルはコンポーネントサービスから変更できる。
スリップストリームセットアップ
製品 + SP + CU を一回でセットアップできる機能
Web キャストにトラブルシューティングがあるのでそちらを確認
コマンドとしてスイッチをつける。
