データベース内の全テーブルのサイズ（ディスク使用量）を取得するクエリー
データベース内の全テーブルのサイズ（ディスク使用量）を取得するには？ データベースサーバの空き容量が少なくなってきて、どのテーブルがディスク容量をたくさん使っているのかな？と調べたい時ありますよね。 ここでは、そんな時に使えるクエリーをご紹介します。 テーブルのサイズ（ディスク使用量）を取得するには テーブルのサイズ（ディスク使用量）を簡単に取得するには sp_spaceused というシステム・ストアド・プロシジャーを使って確認することができます。 この sp_spaceused というストアド・プロシジャーは、パラメターを渡さなければデータベースのサイズを、テーブルなどのオブジェクト名を渡すと、そのオブジェクトのサイズ情報を返してくれます。 例えば、Person.Person テーブルのサイズを取得するクエリーは以下の通りです。 データベースを選択してから実行して下さい。 rows:
SQL Server の読み取り一貫性とロック｜システム開発のブログ｜株式会社ベルソフト
分離レベル SNAPSHOT は SERIALIZABLE と同じで「データに矛盾が生じる3つの現象」が発生しません。 SNAPSHOT は同時実行性がありますが、SERIALIZABLE は同時実行性がありません。 SNAPSHOT は複数のトランザクションが同時に実行された結果、同じデータを更新した場合、後のトランザクションはエラーが生じロールバックします。 ACID特性について 「データに矛盾が生じる3つの現象」には先の表で記載した通りダーティーリード、ノンリピータブルリード、ファントムリードがあります。 （複数のトランザクションを同時に実行すると隔離性が保たれなくなる現象）。 ACID特性の隔離性（Isolation）によって発生しないように分離レベルが定義されています。 ACID特性はトランザクション処理に求められる要素で以下の4つがあります。 ・原始性(Atomicity) ・
SQL ServerよりOracleの方が優れてるなと思った話 - 情シスは何度でも甦るさ。
Oracle社は好きじゃないんだが、OracleDBは好きです。前職では、なんちゃってDBAみたいな役割だったこともあり、Oracle Master Goldも取得した。 ですが、今の会社で昨年基幹システムのリプレースがあり、そのシステムがSQL Serverだったのですが、運用フェーズに入ってSQL Serverと戯れることが多くなりました。 で、改めてOracleの方が優れてるなぁ。という話。コスト的には断然安いからその点は置いとくとして、あくまで運用担当者目線。あと、今回導入したERPのソフトに起因するのもあるけれども、つらつらと書いてみる。 基本機能 読み取り一貫性とロック よく言われるやつなんですが、Oracleの読み取り一貫性がSQL Serverにはない。ということで、色々挙動が変わるのですが、最も影響がでたとこでいうと、SQL ServerのSELECTはデフォルトで、SE
2010-02-25
SQL Server 2008 からは、リソース ガバナ機能がサポートされました。これは、CPU 利用率やメモリ割り当て量といったリソースの調整が行える大変便利な機能です。これにより、CPU を占有するバッチ アプリケーションの CPU 利用率を制限したり、CPU を占有する SQL の CPU 利用率を制限したりするといったことが可能になります。 リソース ガバナは、次のように試すことができます。 まずは、［管理］フォルダで［リソース ガバナ］を右クリックして［新しいリソース プール］をクリックして新しいリソース プールを作成します。 ［リソース ガバナのプロパティ］ダイアログが表示されたら、［リソース ガバナを有効にする］をチェックし、［リソース プール］の［名前］列に「testResourcePool」など、任意の名前を入力します。 次に、リソース プール内へワークロード グループを
DO’s&DONT’s #17: やっておいた方がいいこと - tempdb データファイル数を CPU 数に一致させる
神谷 雅紀 Escalation Engineer KB 2154845 で述べられていますが、一般的には、tempdb データファイルの数は、SQL Server が使用可能な CPU の数に一致させた方が高負荷時のパフォーマンス劣化を防ぐことができるとされています。ただし、2011 年の PASS Conference (PASS : Professional Assosiation for SQL Server) におけるセッション Inside Tempdb で発表されたテスト結果を受けて、8 を超える CPU が使用可能な SQL Server では、tempdb データファイル数は 8 を基準とし、状況を見ながら必要に応じて 4 の整数倍の数のファイルを追加するという方法が推奨されています。 ただ、これを必ずやらなければならないかと言えば、tempdb 負荷の低い環境では必ずし
SQL Server tempdb分割のクエリ - はしろぐ
SQL Serverの設計として、tempdbをサーバーのコア数分分けた方がよいという話をよく聞きます。 じゃぁ分割しようと気軽に思って調べたときに、なかなか具体的な分割手法が検索にヒットせず、だいたいが説明のみで「そういうのいいから、今は分割したいんだ！」という時に歯痒い思いをしました。（理由や背景は知っておいた方がよいというのは別として。） だったら自分自身でメモとして残しておこうと、行動に起こした結果がこの記事です（笑）変数の値を変更すれば流用できるようにしてみました。削除・追記して環境に合わせてカスタマイズしてくださいー。 -- クエリ変数定義 DECLARE @QUERY VARCHAR(max) -- システムデータベースディレクトリ DECLARE @PATH AS varchar(100) = N'C:\Program Files\Microsoft SQL Server\
SQL Server と NUMA at SE の雑記
SQL Server と NUMA の対応について少しまとめてみたいと思います。 手探りで調べている内容なので、間違って理解している個所がいくつかあるかも知れませんが。 BOL としては Non-Uniform Memory Access について に記載されている内容となります。 ■SQL Server と NUMA SQL Server 2000 SP4 以降で SQL Server が NUMA の限定的なサポートをはじまりました。 NUMA がサポートされた環境での導入は携わったことがなく、この辺は知識として知っているだけなのですが、トレースフラグやアフィニティマスクを設定する必要があったようです。 非一様メモリ アクセス (NUMA) を使用するには、SQL Server 2000年を構成する方法 SQL Server 2005 以降で NUMA への対応が本格化されました。 S
64ビット時代の「バランスド・システム」 (3/3)：真・Dr. K's SQL Serverチューニング研修（5） - ＠IT
プロセッサコアの数にかかわらず、32ビット版よりも64ビット版の方が多くのスレッドを生成できることがお分かりいただけるでしょう。そして、ここで思い出してほしいことが、ワーカースレッドスタックの大きさです。32ビット版は1スレッド当たり512KBで、64ビット版は1スレッド当たり2MBでしたね。 つまり、プロセッサコアの数を増やせば増やすほど、多くのメモリを消費する可能性があり、その傾向は64ビット版に顕著だということです。例えば、128コアのハードウェアでは、最大で4480スレッドが動作します、1スレッド当たりのワーカースレッドスタックの大きさが2MBですので、およそ10GBのメモリをワーカースレッドスタックだけで消費するのです。128個ものプロセッサコアを搭載したハードウェアを使うには、それなりに大量のメモリが必要になるということです。 ちなみに、Max Worker Threadsの値
DB管理者がいますぐ確認すべき3つの設定
DB管理者がいますぐ確認すべき3つの設定：真・Dr. K's SQL Serverチューニング研修（4）（1/3 ページ） 管理者の力量があらわれる3つの設定 前回、設定された値を見るだけでDB管理者の力量が見える、ということに触れました。今回も必ず押さえておきたいパラメータを、なぜそのように設定すべきかという理由と併せて解説していきます。 設定すべきポイントは大変シンプルです。 tempdbの数をCPUコア数にあわせよ x64環境なら「メモリ内のページロック指定」を変えよ OLTP環境では、並列処理の最大限度（Max DOP）はCPUコア数の「4分の1」に設定せよ もちろん、これだけ変更すれば、その部分における最低限のチューニングは完了します。しかし1つ上のエンジニアを目指すなら、その理由まできっちり知っておくべきでしょう。その理由を知ることで、監視ツールや動的管理オブジェクトが発する「
Windows Notepad |SQL Server 設計時に考慮したい事項
SQL Serverだけではなく、データーベース製品はハードウェアやOSの動き、データベースのアーキテクチャ など細かい部分を意識した構成が求められます。 このあたり、結構「えいやっ」でやってしまいがちなところですが、 あとから手直しのきかない部分でもあるので、しっかりとした設計を心がけたい部分です。 ＜やるべき設定＞ １．tempdbの数をCPUのコア数に合わせる ・SQLサーバーでは、1つのCPUコアに対して、1つのUSM（ユーザーモード）スケジューラが 割り当てられています。 （USMの数は、SQL Server がCPUのコアの数を認識して同じ数だけ立ち上げる） この（CPUのコア数）スケジューラの数だけtempdbのデータファイルを用意すると 並列でtempdbが利用できるため、処理効率が向上する。 ２．SQLサーバーのサービスアカウントを「メモリ内のページロック」の設定をする
SQLOS のワーカースレッドについて軽くまとめてみました at SE の雑記
SQLOS で管理しているワーカースレッド (Worker Thread) について軽くまとめてみたいと思います。 ■Max Worker Thread について SQL Server の最大ワーカースレッド数を管理する、[max worker threads] オプションですが、デフォルトでは [0] が設定されており、SQL Server のスケジューラー数に応じて自動で設定されるようになっています。 自動で設定された最大ワーカースレッド数については [sys.dm_os_sys_info] から確認することが可能です。 今回は 8 コアの環境 (HT 有り) を使用しており、スケジューラーが 8 個、起動している環境となっています。 そのため、最大ワーカースレッド数は以下のように設定されます。 ■ワーカースレッドの割り当て状況 次にワーカースレッドが実際にどれくらい割り当てられている
max worker threads (サーバー構成オプション) の構成 - SQL Server
適用対象: SQL Server この記事では、SQL Server Management Studio または Transact-SQL を使用して、SQL Server の max worker threads サーバー構成オプションを構成する方法について説明します。 max worker threads オプションは、クエリ要求、ログイン、ログアウト、および同様のアプリケーション要求を処理するために SQL Server 全体で使用できるワーカー スレッドの数を構成します。 SQL Server は、オペレーティング システムのネイティブ スレッド サービスを使用して、次の条件を確認します。 1 つ以上のスレッドが、SQL Server がサポートする各ネットワークを同時にサポートします。 1 つのスレッドがデータベース チェックポイントを処理します。 スレッドのプールがすべてのユー
DO’s&DONT’s #14: 絶対にやってはいけないこと – ひとつの CPU に対して affinity mask と affinity I/O mask の両方を ON にする – Microsoft SQL Server Japan Support Team Blog
神谷 雅紀 Escalation Engineer SQL Server の sp_configure 構成オプションとして、affinity mask, affinity64 mask および affinity I/O mask, affinity64 I/O mask があります。affinity mask は最初の 32 個の CPU 用、affinity64 mask は 33 個目以降の CPU 用である点を除けば、これら 2 つの機能は同じです。affinity I/O mask と affinity64 I/O mask も同様です。 affinity I/O mask が SQL Server の機能として実装された時点から、Books Online をはじめとする多くの技術文書で、affinity mask と affinity I/O mask は重複してはいけないこと
パフォーマンスの監視とチューニング - SQL Server
適用対象: SQL Server Azure SQL Database Azure SQL Managed Instance データベースを監視する目的は、サーバーのパフォーマンスを評価することです。 適切な監視には、現在のパフォーマンスのスナップショットを定期的にキャプチャして問題の原因となっているプロセスを特定したり、長期にわたって継続的にデータを採取してパフォーマンスの傾向を追跡する作業が必要です。 データベース パフォーマンスの継続的な評価は、応答時間を最小限にし、スループットを最大限にして、最適なパフォーマンスを実現するために役立ちます。 パフォーマンスを最大限に高めるには、効率的なネットワーク トラフィック、ディスク I/O、および CPU 使用が重要です。 アプリケーションの要件を十分に分析し、データの論理構造と物理構造を理解し、データベースの使用状況を評価し、競合する処理
システム基盤 AtlasBase®｜BIPROGY株式会社
企業情報 企業情報トップ BIPROGYについて トップメッセージ 会社概要 Purpose,Principles Vision2030・経営方針（2024-2026） コーポレートブランド グループ会社 拠点所在地 組織図 役員一覧 企業理念 企業行動憲章 役職員行動規範 PDF 調達・購買に関する指針等について BIPROGYグループのAI倫理指針 PDF BIPROGYグループの歴史 BIPROGYの企業活動 サステナビリティ 広告宣伝活動 イベント／セミナー 出版物 デジタルメディア BIPROGY TERASU 別ウィンドウで開く BIPROGYバドミントンチーム 東京ディズニーランド「エレクトリカルパレード・ドリームライツ」 東京ディズニーシー「フォートレス・エクスプロレーション」 BIPROGYの研究活動 BIPROGY総合技術研究所 Technology Foresight
SQL Server 2008 R2日本語版のライセンス販売は5月1日から--プロセッサ課金の価格優位性を強調
なお、超大規模並列処理向けにリリースされる新エディション「Parallel Data Warehouse」については、現時点では発売日、価格共に未定だ。 同社では昨年11月に、開発最終段階の評価版である「SQL Server 2008 R2 Community Technology Preview（CTP）11月版」をリリースし、製品投入の準備を続けてきた。その中では、クラウド環境であるSQL Azureとのシームレスな統合によるメリットや最大256の論理CPUをサポートする拡張性の向上といった点が強調されてきたが、今回は価格の発表に合わせ「プロセッサ単位での課金モデルによる価格優位性」について強く訴えた。 マイクロソフト、サーバープラットフォームビジネス本部エグゼクティブプロダクトマネージャーの斎藤泰行氏は、その優位性を説明するため、これまでにリリースされたSQL Serverのバージョ
SQL Server 2017へのアップグレードの方法とアップグレード時の懸念点について
１．アップグレードの方法 まず、アップグレードの方法ですが大きく分けて2つあります。1つは、既存環境のSQL Serverをアップグレードする方法（インプレースアップグレード）で、もう1つは新しい環境を構築し、データベース（データ）を移行してアップグレードする方法（移行）になります。 移行方法 インプレースアップグレードで既存環境のSQL Server 2008をアップグレードする場合、以下バージョンからのアップグレードのみサポートされます。 SQL Server 2008 SP4 以降 SQL Server 2008 R2 SP3 以降 アップグレードの詳細はこちらに記載されておりますので、ご確認ください。 実際にアップグレードする場合、インプレースアップグレードより移行を選択するケースが多いと思います。これは、アップグレード後のテストができない（別環境を用意しないといけない）ことや、万
SQL ServerがLinuxをサポートできた理由--マイクロソフトが明かす歴史
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 日本マイクロソフトは10月26日、データプラットフォームに関するメディア向け勉強会を開催し、同月2日にリリースした「SQL Server 2017」の新機能を中心に解説した。 既報の通りSQL Server 2017では、従来の「Windows専用」という位置付けが大きく変更され、Linuxに対応した。さらに、昨今の機械学習／ディープラーニングの発展を踏まえて「Machine Learning Services」が提供され、GPUとPythonがサポートされる点も注目される。今回の説明会では人工知能（AI）への対応についてデモを交えた説明が行われたが、本稿ではその前提として語られたSQL Serverの内部構造の変化の過程について紹介す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tempdb の分割とその効果についての概要 at SE の雑記
SQL Server 2008ユーザーが2017にアップグレードすることで得られるメリット
