SQL Server 「データベースは使用中なので、排他アクセスを獲得できませんでした」 で復元の失敗時の対処方法 「データベースは使用中なので、排他アクセスを獲得できませんでした」 で復元の失敗 バックアップファイルからデータベースをリストアしようとした時に 「 データベース * の復元に失敗しました。 」 「 データベースは使用中なので、排他アクセスを獲得できませんでした。 」 のようにエラーが出て、復元できない時があると思います。 今回はデータベースが使用中で復元を失敗した時の対処方法です。 利用状況モニター（Activity Monitor） で利用状況を確認する 利用状況モニターを見ると、復元しようとしているデータベースを利用しているプロセスなどを確認することができます。 SQL Server Management Studio の オブジェクトエクスプローラでサーバーを右クリッ

こんにちは、プラチナホルダー浜辺です。 最近、大規模システムで「 RMAN によるDBバックアップが遅い」 という相談が増えておりますので、 本記事にてDBバックアップ時間を短くするテクニックをご紹介します。 ※注意※ 本記事ではDBバックアップの取得方法として RMAN の利用を前提としております。 プラチナホルダー浜辺執筆＆登場記事はこちらを参照ください！（一部紹介） 新年1発目の講演してきました！ PDBの作成方法 PDBの自動起動 DBバックアップが遅い原因は？ RMAN のDBバックアップですが、ざっくりと以下の流れで行われます。 一般的にDBバックアップに時間が掛かる要因としては、以下が考えられます。 [1. 読み込みフェーズ] ・DBファイルの配置先が低速なディスクである ・DBファイルの配置先のディスクにアクセスが集中している ・ネットワーク帯域が狭い（不足） [ 2. コ

ふと気づいた。 select * from table1 where id in(@param) というような形で「@paramに動的な複数値をカンマ区切りで渡したい」と いう要望は結構ある。しかしこの状態では期待した結果にならないので executeやsp_executesql(動的SQL実行)を使う execute ('select * from table1 where id in('+@param+')') これは期待通りの結果になるのだが、いかんせんAccessと相性が悪いため (カラム名が解決できないのでコントロールソースが手入力になるなど)SQLCLRを使って カンマ区切りをテーブルにして返す関数(Split)を作成すると良いと最初は思いました。 苦労してSQLCLRを調べたりしたんですがそんなことしなくてもできます。 もちろん動的実行しなくてもできます。こうすればよかったん

適用対象: Azure Synapse Analytics この記事では、ソリューション開発用の Azure Synapse Analytics の CREATE MATERIALIZED VIEW AS SELECT T-SQL ステートメントについて説明します。 この記事には、コード例も記載されています。 具体化されたビューでは、ビュー定義クエリから返されるデータを保持し、基になるテーブルのデータが変更されると自動的に更新されます。 これによって、複雑なクエリ (一般に結合と集計を含むクエリ) のパフォーマンスが向上すると共に、メンテナンス操作が簡単になります。 実行プランの自動一致機能により、置換するビューをオプティマイザーで検討する際、具体化されたビューをクエリで参照する必要はありません。 この機能により、データ エンジニアは、クエリを変更せずにクエリの応答時間を短縮するメカニズム

こんにちは、管理人のPaZooです。 性能調査など負荷試験を行う時に、SQLServerのテーブルに大量のデータをinsertするケースがありましたのでその時に調べた内容を記事にしました。 データを大量に作成するとなると時間がかかって大変でしたが、とても良い経験になりましたのでお役に立てれば幸いです。 テスト環境を整える サンプルデータベースの作成 サンプルテーブルの作成 ループを使ってレコードを作成するクエリ 再帰SQLで大量のテストデータをinsertする まとめ テスト環境を整える まずは実行する環境を整えます。 【実行環境】SQL Server2019 Express(64bit) サンプルデータベースの作成 テスト用にまずはデータベースを作成します。データベースの作成は下記の記事が分かりやすかったので、ぜひ参考にされてください。 sql-oracle.com 私はサンプルデータベ

前回の投稿ではソート時に tempdb が利用されたことを、実行プランから確認しました。 今回は拡張イベントでソート時の tempdb の利用を確認してみたいと思います。 ■Sort Warning イベントの発生 ソート時に tempdb が利用されると実行プランに警告が表示されます。 この時、[Sort Warning] というイベントが発生しています。 tempdb を使用したソートが行われたかどうかはこのイベントを取得することで確認ができます。 確認の方法としては、SQL Server Profiler / 拡張イベントがあります。 SQL Server Profiler で確認する場合は Errors and Warnings の Sort Warnings というイベントを取得すること確認ができます。 拡張イベントの場合は、sort_warning のイベントを取得することで確

適用対象: SQL Server Azure SQL Database Azure SQL Managed Instance Sort Warnings イベント クラスは、並べ替え操作をメモリ内で処理できないことを示します。 インデックスの作成に関連する並べ替え操作は対象になりません。SELECT ステートメントで使用される ORDER BY 句などのクエリ内の並べ替え操作のみが対象になります。 並べ替え操作を伴うクエリで Sort Warnings イベント クラスが発生し、EventSubClass データ列の値が 2 である場合は、データを並べ替えるためにデータを複数回受け渡す必要があるため、クエリのパフォーマンスが低下する可能性があります。 クエリをさらに検証し、並べ替え操作を排除できるかどうかを確認してください。 Sort Warnings イベント クラスのデータ列 データ列

引用は主に以下から。 [INF] SQL Server における自動拡張および自動圧縮の構成に関する注意事項 http://support.microsoft.com/kb/315512/ja SQL Server データベースのいっぱいになったトランザクション ログからの回復 http://support.microsoft.com/kb/873235/ja 1.自動拡張を行っている間、トランザクションが停止する。 ログを拡張する必要がある大規模なトランザクションを実行する場合、そのトランザクション ログに書き込む必要がある他のトランザクションも、拡張操作が完了するまで待機する必要があります。 これによりクエリタイムアウトも起きやすくなりそうです。 2.ファイルの断片化が招きやすくなり、パフォーマンスに影響が出る。 データ ファイルまたはログ ファイルのサイズ変更に起因する物理的な断片化

元の製品バージョン: SQL Server 元の KB 番号: 315512 まとめ 既定の自動拡張と自動圧縮の設定は、多くの SQL Server システムで適切です。 ただし、環境によっては、自動拡張と自動圧縮のパラメーターの調整が必要です。 この記事では、環境に合わせてこれらの設定を選ぶときの目安となる背景情報について説明します。 自動拡張と自動縮小のパラメーターを調整する場合は、次の点を考慮する必要があります。 設定を構成操作方法 自動拡張と自動圧縮の設定は、次のいずれかを使用して構成または変更できます。 SQL Server Management Studio ALTER DATABASE ステートメント File オプションとファイル グループ オプションを使用自動拡張設定を変更する SET オプションを使用してAUTO_SHRINK設定を構成します。 データベースの作成時に自

この記事はSilbird Advent Calendar 2017 8日目の記事となります。 弊社では、稼働中のサービスの永続化データ格納先としてAmazon RDS for SQL Serverを利用しています。 その中で経験したDB領域の拡張と縮小について、大きな2つのトラブル事例とその対応内容をご紹介しようと思います。 DB領域の拡張、縮小はサービスを一時的止める（メンテナンスに入れる）た状態でないとできないと思われがちですが、サービス稼働中のまま実行することができます。 [事例1] DB自動拡張中に応答停止 1つめはDBの自動拡張についてです。 DBの初期容量は、想定ユーザー数やアクセス数をもとにある程度余裕を持って見積もっていると思います。しかし、Webサービスの世界ではその見積もりどおりにユーザーが増えていくとは限りません。サービス運営者としては嬉しい悲鳴ですが、ユーザー数・滞

SQL Server / SQL Database の実運用環境では、ロックについて悩まされることが多々あるのではないでしょうか。 SQL Server のロックの基本的な動作の理解はトラブルシューティングでは重要となりますので、SQL Server のロックの基礎について、本シリーズでもまとめておきたいと思います。 今回は次のようなテーブルを例にして、解説を行いたいと思います。 SET NOCOUNT ON GO DROP TABLE IF EXISTS LockTEST CREATE TABLE LockTEST( C1 int identity primary key, C2 varchar(36) DEFAULT NEWID(), C3 float DEFAULT RAND() * 10, C4 float DEFAULT RAND() * 100 INDEX NCCIX_Lock

神谷 雅紀 SQL Server Escalation Engineer クエリタイムアウトまたはコマンドタイムアウト (Query Timeout/Command Timeout, 以降クエリタイムアウト)、使用するデータアクセスインタフェースにより呼び名は異なりますが、どちらも指定した時間が経過した後、実行中の処理を中断する機能です。 これらのタイムアウトに関して、「クライアントプログラムを変更せず、SQL Server データベースエンジン側の設定で、クエリタイムアウトを発生させないようにすることはできないか？」という質問を受けることがあります。答えは、「できない」です。その理由は、クエリタイムアウトは、クライアント側で動作するデータアクセスインタフェース (OLE DB プロバイダ、ODBC ドライバ、 SqlClient など) によって実装されている機能であるためです。SQL