開発のあいまに

メソッドの実行数や実行時間を解析できる無料のMicrosoftツール(WPA)

Windows Performance Analyzerの使い方。
http://blogs.msdn.com/b/jpwdkblog/archive/2014/11/28/windows-performance-analyzer.aspx

ダウンロード先。
https://msdn.microsoft.com/en-us/library/windows/desktop/hh448170.aspx

Windows OS が不安定になったら、Cドライブの不良セクタをスキャン

Windows OS の動きが不安定で、OSを再起動しても動きがおかしいなと感じた際は、Cドライブの不良セクタスキャンを行うと、OSが安定する事がわりとあります。古いHDDを使っている場合は特に、時々は不良セクタスキャンを行うのがお勧めです。

※不良セクタスキャンはOSを再起動する必要はなく、Windowsを普通に使いながらでもできます。

Cドライブを右クリックして、プロパティ画面から実行できます。

Order2Go COM API 最新版

1、FXCMジャパンのAPIダウンロードサイトから、インストーラをダウンロードする。

　Trading API 概要ページを見ると、FX自動トレードを行う為のアプリケーションを作成し接続できるのは、法人限定のような印象を持つが、FXCMジャパンの窓口へ問い合わせしたところ、個人が使ってもライセンスや規約の問題は発生しないとのこと。

 

2、FXCMFXOrder2Go.EXE をダウンロードできたらインストールする。

　APIは C:\Program Files (x86)\Candleworks\FXOrder2Go へインストールされる。

 

3、C:\Program Files (x86)\Candleworks\FXOrder2Go\RunFXCMOrder2Go.bat をクリックして実行すると、最新のライブラリに更新される。

 

Windows7 にDBを構築する場合、シャドウコピーを無効にしないと、処理性能が極端に低下する

Windows7 に SQLServer 2008/2012 をインストールして、DBサーバーとして利用していますが、DBサイズが50GBを超えた辺りから、定期的にDBの処理性能が10分の1に低下する現象が、発生するようになりました。

DBサイズが増加するにつれ、その頻度が多くなり、継続時間も長くなってきたので、本格的に調査した結果、Windows7のシャドウコピーが原因だと分りました。

シャドウコピーを無効にする事で、処理性能が極端に低下する事は無くなり、Windows7 でも 社内DBサーバーとして十分活用できています。

シャドウコピーを無効化する方法は、こちらを参考にして下さい。
http://www.se-support.com/clientpc/volumeshadow.html

シャドウコピーが無効になっている状態はこちら。

SQLServerで、IISからのDB処理だけが遅い現象が、どうしても解決しない場合は、ヒント文を使用する

SQLServerで時々発生する、IISや関連サービスからのDB処理だけが、極端に遅くなる現象に対応する為、４つのサイクルを回して来たのですが、運用時間帯に、一部の処理で、IISや関連サービスからのDB処理だけ、極端に遅くなる現象が再発してしまいました。

【４つのサイクル】
1、チューニングアドバイザーによる、インデックスと統計情報の抽出と追加。
2、テーブルの統計情報を、週次で更新。
3、ストアドとファンクションを、日次のジョブで毎朝リコンパイル。
4、IISと関連サービスを、日次で毎朝再起動。

【環境】
WEBサーバー：Windows Server 2008 R2 SP1
DBサーバー：Windows Server 2008 R2 SP1、SQLServer 2008 R2 SP2 CU5
WEBサイトは.Net4.0で構築

IISや関連サービスからだと数時間かかっている処理でも、SQLServer Management Studio から実行すると数秒で終わり、関連するストアドとファンクションをリコンパイルすると、IISや関連サービスからの処理も数秒で終わるようになるので、ストアドとファンクションがキャッシュしている実行プランに、問題があるのは確実なのですが、４つのサイクルでは解消しませんでした。

最終手段として、ストアドとファンクション内のSelect文が使用するインデックスを、ヒント文で固定する事で、解消することが出来ました。

具体的には、Management Studioから実行すると速い環境で使用されているインデックスを調査し、ヒント文でそのインデックスを固定する事で、どの環境でも必ず同じインデックスが使われるようにします。

【具体的な手順】
1、SQLServer Management Studio でSQLを右クリックし「推定実行プランの表示」を選択する。
2、表示された実行プランを右クリックし「実行プランのXMLの表示」を選択する。
3、表示されたXMLの中から「Index="」が有る行を検索する。
　XMLからだと、どのSelect 文のどのテーブルが、どのインデックスを使っているか、簡単に
　見つける事ができます。
　プライマリキーは無視して構いません。
4、見つかったインデックスは、ヒント文（ WITH (index( ）として、FROM句のテーブルの後に
　宣言し、そのSQLで使用されるインデックスを固定します。

ストアドやファンクションそれぞれの中で、各テーブルの別名を、ユニークになる名称にしていると、より簡単に対象のインデックスを見つける事ができます。

【ヒント文の例】
・1つのテーブルに1つのインデックスを指定する場合。
FROM （テーブル名） as （テーブル別名）
WITH (index(（インデックス名１）))

・1つのテーブルに複数のインデックスを指定する場合。
FROM （テーブル名） as （テーブル別名）
WITH (index(（インデックス名１）,（インデックス名2）))

※ヒント文に指定するインデックスは、NONCLUSTURED INDEX のみでよく、プライマリキーを含む CLUSTURED INDEX  を指定する必要はありません。

SQLServerのインデックスと統計情報については、５つのサイクルを回す事で、パフォーマンスの問題を解決できそうです。

【５つのサイクル】

1、チューニングアドバイザーによる、インデックスと統計情報の抽出と追加。
2、テーブルの統計情報を、週次で更新。
3、ストアドとファンクションを、日次のジョブで毎朝リコンパイル。
4、IISと関連サービスを、日次で毎朝再起動。
5、IISと関連サービスからのDB処理が、極端に遅くなるストアド、ファンクションは、使用するインデックスをヒント文で固定する。

 

【関連記事】
チューニングアドバイザーによる、インデックスと統計情報の抽出と追加
テーブルの統計情報を、週次で更新
ストアドとファンクションを、日次のジョブで毎朝リコンパイル
IISと関連サービスを、日次で毎朝再起動。
IISと関連サービスからのDB処理が、極端に遅くなるストアド、ファンクションは、使用するインデックスをヒント文で固定する
SQLServerで、IISからのDB処理だけが遅い場合は、ストアドをリコンパイルする
SQLServer 2005 インデックス チューニング ライフサイクル
6ヶ月以上使われていないインデックスを抽出するSQL

SQLServerで、ストアド、ファンクションをリコンパイルしても、IISからのDB処理だけが遅い場合は、IISを再起動する。

SQLServerで、IISからのDB処理だけが遅い場合は、ストアド、ファンクションをリコンパイルするを繰り返しても、「IISからのDB処理だけが遅い」現象が、解消されないことがありました。

その時は、IISを再起動する事で、解消しました。

【環境】
WEBサーバー：Windows Server 2008 R2 SP1
DBサーバー：Windows Server 2008 R2 SP1、SQLServer 2008 R2 SP2 CU5
WEBサイトは.Net4.0で構築

 

【関連記事】
チューニングアドバイザーによる、インデックスと統計情報の抽出と追加
テーブルの統計情報を、週次で更新
ストアドとファンクションを、日次のジョブで毎朝リコンパイル
IISと関連サービスを、日次で毎朝再起動。
IISと関連サービスからのDB処理が、極端に遅くなるストアド、ファンクションは、使用するインデックスをヒント文で固定する
SQLServerで、IISからのDB処理だけが遅い場合は、ストアドをリコンパイルする
SQLServer 2005 インデックス チューニング ライフサイクル
6ヶ月以上使われていないインデックスを抽出するSQL

SQLServerで、インデックスと統計情報を追加しても、ストアドの処理が遅い場合

ストアドをチューニングアドバイザーに掛け、抽出されたインデックスと統計情報を追加すれば、ストアドのパフォーマンスを大幅に改善する事ができます。
それは、テラバイトクラスのDBシステムでも同様です。

しかし、テラバイトクラスのDBだと、統計情報の更新、インデックス再構築に1日以上かかり、夜間ジョブとして実行することができない場合があります。

その場合、実際のデータと、そのデータを持つテーブルの統計情報とで、乖離が大きくなり、ストアドが使用する実行プランが、最適ではなくなり、極端にパフォーマンスが低下します。

そうなると、いくらストアドをリコンパイルしても、パフォーマンスは改善しません。

このケースでは、テーブル自体の統計情報を更新した後、ストアドをリコンパイルする事で、パフォーマンスが改善されます。

具体的には、こちらのSQLを実行します。
UPDATE STATISTICS （テーブル名）;
EXEC sp_recompile N'（テーブル名）';

 

【関連記事】
チューニングアドバイザーによる、インデックスと統計情報の抽出と追加
テーブルの統計情報を、週次で更新
ストアドとファンクションを、日次のジョブで毎朝リコンパイル
IISと関連サービスを、日次で毎朝再起動。
IISと関連サービスからのDB処理が、極端に遅くなるストアド、ファンクションは、使用するインデックスをヒント文で固定する
SQLServerで、IISからのDB処理だけが遅い場合は、ストアドをリコンパイルする
SQLServer 2005 インデックス チューニング ライフサイクル
6ヶ月以上使われていないインデックスを抽出するSQL

SQLServerで、IISからのDB処理だけが遅い場合は、ストアド、ファンクションをリコンパイルする

テラバイトクラスのDBシステムを扱っていると、データ量が増えるたびに、特定のSQLが極端に遅くなることがあります。

その時に、遅くなったSQLの実行プランを確認すると、インデックススキャン（Index seek）のコストが跳ね上がり、SQL全体のコストの100%近くを、インデックススキャンが占めるように変化しています。

インデックススキャンのコストは、SQL全体で20%未満になっているのが、妥当な値です。

極端に遅くなっている、もしくは、コストが高くなっているSQLは、SQLServerのチューニングアドバイザーにかけると、インデックスと統計情報が抽出されるので、それを適用する事で解決できます。
※SQLが遅くなっているサーバーで、チューニングアドバイザーを実行せず、別のサーバーでチューングアドバイザーにそのSQLをかけると、必要なインデックスと統計情報が抽出されない事があるので、そこは注意が必要です。

テラバイトクラスのDBシステムを1年以上運用していて、今回初めて、必要なインデックスと統計情報を追加しても、IISからのDB処理だけ処理性能が改善しない、という現象に遭遇しました。
Management Studioからだと、遅くなっているSQLの実行プランは改善され、実行時間も1秒程度なのに対し、WEBサイトからそのSQLを実行すると、5分たっても結果が返って来ませんでした。

【環境】
WEBサーバー：Windows Server 2008 R2 SP1
DBサーバー：Windows Server 2008 R2 SP1、SQLServer 2008 R2 SP2 CU3
WEBサイトは.Net4.0で構築

色々試した結果、WEBサイトから実行した場合のみ遅い現象が発生したら、ストアドのリコンパイルが有効だという事が分かりました。ユーザー定義関数を利用している場合は、関数のリコンパイルも必要です。

ストアドに実行プランをキャッシュする、こちらのアーキテクチャにバグがあって、IIS側からアクセスされた場合に、古い実行プランを使い続けていたのが原因でした。
http://msdn.microsoft.com/ja-jp/library/ms181055(v=sql.105).aspx
http://msdn.microsoft.com/ja-jp/library/ms191007(v=sql.105).aspx

そういえば、SQLServerはIISのキャッシュを、別扱いするという技術資料を、以前どこかで読んだ気がします。

毎日のように、インデックスと統計情報を追加しているシステムなので、再発防止として、インデックスと統計情報を追加する頻度の高いテーブル、ストアド、ユーザー定義関数は全て、日次で夜間に、sp_recompile を実行するようにしました。
http://msdn.microsoft.com/ja-jp/library/ms181647.aspx

 

【関連記事】
チューニングアドバイザーによる、インデックスと統計情報の抽出と追加
テーブルの統計情報を、週次で更新
ストアドとファンクションを、日次のジョブで毎朝リコンパイル
IISと関連サービスを、日次で毎朝再起動。
IISと関連サービスからのDB処理が、極端に遅くなるストアド、ファンクションは、使用するインデックスをヒント文で固定する
SQLServerで、IISからのDB処理だけが遅い場合は、ストアドをリコンパイルする
SQLServer 2005 インデックス チューニング ライフサイクル
6ヶ月以上使われていないインデックスを抽出するSQL

 

Windows Server で使えるコマンドリファレンス（マイクロソフト公式）

Windows Server で使えるコマンドのリファレンスを、マイクロソフトが公開しています。本を買う必要が無くなりました。

Windows Server コマンド ライン リファレンス

 

System.Runtime.Serialization エラーが発生したら

Windows Server 2008 R2 SP1　x64 に .NET Framework 4.0 をインストールし、IIS上に.NET Framework 4.0 のWEBサイト構築した後、WCFにアクセスすると、こちらのエラーが発生する事があります。

Could not load file or assembly 'System.Runtime.Serialization, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes' or one of its dependencies. The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)

このエラー、もしくは「Could not load file or assembly」関連のエラーが発生する場合は、NDP40-KB2468871-v2-x64.exe　をインストールする事で解決できます。