データベース管理者

クエリを記述しようとすると、SQL Serverはクエリを実行するときにSELECTを解析する前に、クエリ内のWHEREを解析する（難しい方法）ことがわかりました。 MSDNドキュメントは、一般的な論理解析順序はSELECTは（したがって、「そのようなオブジェクト[別名」エラーは他の句の列別名を使用しようとしない場合に得られた）、ほぼ最後に解析されるようなものであると言います。エイリアスをどこでも使用できるようにする提案もありましたが、MicrosoftチームはANSI規格への準拠の問題を挙げてこれを打ち倒しました（この動作はANSI規格の一部であることを示唆しています）。 プログラマー（DBAではない）として、この動作がやや紛らわしいことに気づきました。列エイリアスを持つという目的を大幅に無効にしているように思われるためです（少なくとも、列エイリアスは、実際にエイリアスを使用できる場所はORDER BY のみであるため、クエリの実行の早い段階で解析されます）。プログラマーとしては、クエリをより強力で便利に、そしてDRYにする大きな機会を逃しているようです。 それは理にかなっているほど明白な問題のように見えますが、SELECTとORDER BY以外では列エイリアスを許可しないことを決定する他の理由がありますが、それらの理由は何ですか？

16 sql-server  alias 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、データベース管理者のStack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 すぐに、非常に負荷の高いpostgresqlデータベースをいくつか用意する予定です。mysqlデータベースを高負荷で管理しているのですが、今はpostgresqlを使用する必要があります。 日々のデータベース管理とステータスレポートに最適なツールを教えてください。（もちろんコンソールは最高のものですが、他のオプションについても知りたいです） すべての経験は大歓迎です！

16 postgresql  monitoring 

グーグル検索中に、矛盾する情報を見つけました。 一部のサイトでは、データ用の物理メモリが残っていない場合、SQL Serverは既存のデータをTEMPDBに移動すると述べています（SQL Server：TempDbの説明と推奨事項を参照）。 しかし、他のサイトでは、十分な物理メモリが残っていない場合、オペレーティングシステムがPAGE FILEを使用して物理メモリからデータをそこに移動できると述べています（SQL Serverのページファイルを参照）。 SQL Serverが物理メモリを使い果たしたときにデータを書き込む場所はどこでしょうか？tempdbまたはOSページファイルに？それとも両方とも？

16 sql-server  sql-server-2014  memory  tempdb  data-pages 

他の人とSQL Serverデータベースを作成しています。テーブルの1つは小さく（6行）、データはおそらく一定のままです。新しい行が追加される可能性はほとんどありません。テーブルは次のようになります。 CREATE TABLE someTable ( id int primary key identity(1,1) not null, name varchar(128) not null unique ); INSERT INTO someTable values ('alice', 'bob something', 'charles can dance', 'dugan was here'); 私はそのname列の文字の長さを調べていますが、その値はおそらく32文字を超えることは決してなく、おそらく24文字を超えることはないと思います。この列を変更する利点はありますか、たとえば、varchar(32)？ また、デフォルトの列サイズを4、8、32などの倍数に維持することには利点がありますか？

16 sql-server  database-design  varchar 

一時テーブルを使用するストアドプロシージャを作成しました。SQL Serverでは、一時テーブルはセッションスコープであることを知っています。ただし、セッションで何ができるかについての明確な情報を見つけることができませんでした。特に、このストアドプロシージャが1つのセッションで2回同時に実行できる場合、2つの実行が一時テーブルを共有するため、そのプロシージャ内のトランザクションには非常に高い分離レベルが必要です。

16 sql-server  sql-server-2012 

現在、完全に機能する既存のデータベースとアプリケーションがあります。この時点でアーキテクチャを変更することはできません。今日、データベース内の各テーブルには、「IsDeleted」NOT NULL BITフィールドがあり、デフォルトは「0」です。アプリケーションがデータを「削除」すると、IsDeletedフラグが1に更新されます。 私が理解できないのは、各テーブルのインデックスの構成方法です。現在、すべてのquery / join / etcは常にIsDeletedチェックを実装しています。開発者が従わなければならない標準です。そうは言っても、各テーブルのクラスター化プライマリキーインデックスをすべて変更して、プライマリキーとIsDeleted BITフィールドを含める必要があるかどうかを判断しようとしています。また、すべてのquery / join / etcから。IsDeletedチェックを実装する必要がありますが、すべての単一のインデックス（非クラスター化）がIsDeletedフィールドをインデックスの最初のフィールドとして含むべきであるという適切な仮定ですか？ もう1つの質問は、フィルター選択されたインデックスに関するものです。「WHERE IsDeleted = 0」などのインデックスにフィルターを適用して、インデックスのサイズを小さくできることを理解しています。ただし、すべての結合/クエリはIsDeletedチェックを実装する必要があるため、（結合/クエリでIsDeleted列が使用されるため）フィルター選択されたインデックスが使用されないようにしますか？ 私は、IsDeletedアプローチを変更する能力がないことを忘れないでください。

16 sql-server  sql-server-2012  index 

2つの未加工、つまりフォーマットされていないパーティションを使用してデータベースを作成しようとしています。 Microsoft Docsでは、これを実行できると述べています。次のように、rawパーティションのドライブ文字のみを指定するだけです。 CREATE DATABASE DirectDevice ON (NAME = DirectDevice_system, FILENAME = 'S:') LOG ON (NAME = DirectDevice_log, FILENAME = 'T:') ただし、SQL Server 2017は次のエラーを返します。 メッセージ5170、レベル16、状態4、行1 ファイル 'S：'は既に存在するため作成できません。ファイルパスまたはファイル名を変更して、操作を再試行してください。 メッセージ1802、レベル16、状態4、行1 CREATE DATABASEが失敗しました。リストされている一部のファイル名を作成できませんでした。関連するエラーを確認してください。 ドキュメントの適切な部分には次のように記載されています。 ファイルがrawパーティションにある場合、os_file_nameは既存のrawパーティションのドライブ文字のみを指定する必要があります。各rawパーティションに作成できるデータファイルは1つだけです。 そして、はい、ドライブS：とT：はどちらも私のシステムに存在する未フォーマットのrawパーティションです： DISKPART>詳細パーティション パーティション4 タイプ：ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 非表示：いいえ 必須：いいえ 属性：0000000000000000 バイト単位のオフセット：999934656512 ボリューム### LtrラベルFsタイプサイズステータス情報 ---------- --- ----------- ----- ---------- ------- ---- ----- …

16 sql-server  storage 

ここにあるシステム運用者（またはこの経験を以前に経験したことのある人）に対する質問があります。 私の会社は、運用中の既存のSQL Serverボックスに追加のディスク領域を割り当てたいと考えています。ボリュームの拡張（ディスクの管理の「ボリュームの拡張...」）をオンラインで実行できるのか、またはSQL Serverサービスをシャットダウンする必要があるのか​​疑問に思っています。 これを行うためにSQL Serverサービスを停止する必要がある理由、または日中にこの操作を実行するだけでよいのですか？ システム仕様が関連する場合に備えて。これは、Windows 2012 R2およびSQL Server 2008 R2を実行する実際のボックス（仮想化なし）です。 ありがとう！

16 sql-server  sql-server-2008-r2  disk-space  hardware 

強力なサーバーでSQL Server 2014を実行している約1 TBの大規模データベースがあります。数年はすべてうまくいきました。約2週間前に、次のような完全なメンテナンスを行いました。すべてのソフトウェアアップデートをインストールします。すべてのインデックスを再構築し、DBファイルを圧縮します。ただし、実際の負荷が同じ場合、特定の段階でDBのCPU使用率が100％から150％増加するとは予想していませんでした。 多くのトラブルシューティングを行った後、非常に単純なクエリに絞り込みましたが、解決策が見つかりませんでした。クエリは非常に簡単です。 select top 1 EventID from EventLog with (nolock) order by EventID 常に約1.5秒かかります！ただし、「desc」を使用した同様のクエリには常に約0ミリ秒かかります。 select top 1 EventID from EventLog with (nolock) order by EventID desc PTableには約5億行があります。データ型がbigint（Identity列）EventIDのプライマリクラスター化インデックス列（ordered ASC）です。上部のテーブルにデータを挿入する複数のスレッド（より大きなEventID）があり、下部からデータを削除する1つのスレッド（より小さなEventID）があります。 SMSSでは、2つのクエリが常に同じ実行プランを使用することを確認しました。 クラスター化インデックススキャン。 推定および実際の行番号は両方とも1です。 推定および実際の実行回数は両方とも1です。 推定I / Oコストは8500です（高いようです） 連続して実行した場合、クエリコストは両方で同じ50％です。 インデックス統計を更新しましたがwith fullscan、問題は続きました。インデックスを再構築しましたが、問題は半日消えたようですが、戻ってきました。 IO統計をオンにしました： set statistics io on 次に、2つのクエリを連続して実行し、次の情報を見つけました。 （最初のクエリについては、遅いクエリ） テーブル「PTable」。スキャンカウント1、論理読み取り407670、物理読み取り0、先読み読み取り0、lob論理読み取り0、lob物理読み取り0、lob先読み読み取り0。 （2番目のクエリ、高速クエリの場合） …

16 sql-server  sql-server-2014  query-performance  select  top 

tl; dr：CHECKDBがメモリ最適化テーブルを持つユーザーデータベースのトランザクションログを読み取るのはなぜですか？ CHECKDBは、データベースの1つ（特に、インメモリOLTPテーブルを使用するデータベース）をチェックするときに、ユーザーデータベースのトランザクションログファイルを読み取っているようです。 このデータベースのCHECKDBはまだ妥当な時間内に終了するため、ほとんどの場合、動作に興味があります。ただし、このインスタンス上のすべてのデータベースのCHECKDBの期間は間違いなく最長です。 Paul Randalの叙事詩「あらゆる角度からのCHECKDB：すべてのCHECKDBステージの完全な説明」を見ると、データベースの一貫性のあるビューを取得するために、SQL 2005より前のCHECKDB がログを読み取っていたことがわかります。ただし、これは2016年なので、内部データベーススナップショットを使用します。 ただし、スナップショットの前提条件の 1つは次のとおりです。 ソースデータベースにMEMORY_OPTIMIZED_DATAファイルグループを含めることはできません ユーザーデータベースにはこれらのファイルグループのいずれかがあるため、スナップショットがテーブルから外れているように見えます。 CHECKDBドキュメントによると： スナップショットを作成できない場合、またはTABLOCKが指定されている場合、DBCC CHECKDBはロックを取得して必要な整合性を取得します。この場合、割り当てチェックを実行するには排他的なデータベースロックが必要であり、テーブルチェックを実行するには共有テーブルロックが必要です。 さて、スナップショットの代わりにデータベースとテーブルのロックを行っています。しかし、それでもトランザクションログを読み取る必要がある理由は説明されていません。それで何が得られますか？ シナリオを再現するために、以下のスクリプトを提供しました。それは使用していますsys.dm_io_virtual_file_statsログファイルの読み取りを識別するためします。 ほとんどの場合、ログの小さな部分（480 KB）を読み取りますが、それよりもはるかに多く（48.2 MB）を読み取ります。私の実稼働シナリオでは、CHECKDBを実行する深夜に、毎晩ほとんどのログファイル（2 GBファイルのうち約1.3 GB）を読み取ります。 スクリプトでこれまでに得た出力の例を次に示します。 collection_time num_of_reads num_of_bytes_read 2018-04-04 15:12:29.203 106 50545664 またはこれ： collection_time num_of_reads num_of_bytes_read 2018-04-04 15:25:14.227 1 491520 メモリ最適化オブジェクトを通常のテーブルに置き換えると、出力は次のようになります。 collection_time num_of_reads num_of_bytes_read 2018-04-04 15:21:03.207 0 0 CHECKDBがログファイルを読み取るのはなぜですか？そして特に、なぜログファイルのはるかに大きな部分を時々読むのですか？ 実際のスクリプトは次のとおりです。 -- let's …

16 sql-server  sql-server-2016  transaction-log  dbcc-checkdb 

データベースロール、、ストアドプロシージャとして定義されたuser1関数、something()および次のように作成されたビューを指定します。 CREATE VIEW view1 AS select * from something() そして、この許可が与えられた場合： REVOKE ALL ON FUNCTION something FROM user1 REVOKE SELECT ON view1 FROM user1 実行するSELECT * FROM view1と、エラーが発生しますpermission denied for function something()。 私の質問は、ビューの選択権限を取り消すと、なぜ関数が呼び出されるのですか？私は次のようなものを受け取ることを期待していました： permission denied for relation view1 ありがとうございました！

16 postgresql  permissions  view 

私の問題（あるいは少なくとも、エラーメッセージは）非常によく似ているクエリプロセッサの内部リソースを使い果たした-非常に長いSQLクエリを。 私の顧客は、正確に100,000エントリのwhere-clauseを含むSQL select-queryを使用しています。 クエリはエラー8632とエラーメッセージで失敗します 内部エラー：式サービスの制限に達しました。クエリで潜在的に複雑な式を探し、それらを単純化してみてください。 このエラーメッセージが正確に100,000エントリでスローされることは非常に奇妙であるため、これが設定可能な値であるかどうか疑問に思います。これは事実ですか？そうであれば、この値をより高い値に増やすにはどうすればよいですか？ 上のMSDN、そこにクエリを再書き換えるための提案ですが、私はこの問題を回避したいと思います。 一方、私が話しているエントリのリストには自然数が含まれていることがわかりました。それらのかなりの数は連続しているように見えます（ 13,15,16,17,18,19,20）。 これにより、SQLのwhere句は次のようになります。 where entry in (1,2,3,6,7,8,9,10,12,13,15,16,17,18,19,20) これを次のように変換できます。 where (entry between 1 and 3) OR (entry between 6 and 10) OR (entry between 12 and 13) OR (entry between 15 and 20) これは次の方法で短縮できますか？ where entry in (1,...,3,6,...,10,12,13,15,...,20) ...または同様のものですか？（私はそれがロングショットであることを知っていますが、それはソフトウェアの更新をより簡単で読みやすくするでしょう） 参考までに、where-clauseのデータは計算の結果であり、別のテーブルで行われます。最初にそのテーブルのエントリが読み取られ、最初にフィルタリングされ、次に追加の処理が行われます（使用することは不可能です） SQL）、その追加処理の結果はより多くのフィルタリングであり、その結果はwhere-clauseで使用されます。SQLで完全なフィルタリングを記述することは不可能であったため、前述の方法が使用されています。where-clauseの内容は処理ごとに変わる可能性があるため、動的なソリューションが必要であることは明らかです。

16 sql-server  configuration  limits 

MySQL 5.6にはオンラインDDLが導入されたため、ALTER TABLEコマンドにはオプションでいずれALGORITHM=INPLACEかをALGORITHM=COPY指定または指定できます。オンラインDDLの概要では、デフォルトでINPLACEは可能な限り使用され、アルゴリズムが安価であることを（まったく述べずに）示していINPLACEますCOPY。 それではALGORITHM=COPY、ALTER TABLEステートメントで指定しなければならない理由は何ですか？

16 mysql  alter-table  ddl  online-operations 

ではWHERE、SQLクエリの句私は、これら2つの条件が同じ振る舞いを持つことを期待します： NOT (a=1 AND b=1) 対 a<>1 AND b<>1 最初の条件は期待どおりに動作し、2番目の条件を実行して同じことを行いますが、そうではありません。 これは非常に基本的なことですが、恥ずかしいことに、私が間違っていることを見ることができません。

16 condition 

なぜx IS NOT NULL等しくないのNOT x IS NULLですか？ このコード： CREATE TABLE bug_test ( id int, name text ); INSERT INTO bug_test VALUES (1, NULL); DO $$ DECLARE v_bug_test bug_test; BEGIN RAISE NOTICE '%: %', v_bug_test, (v_bug_test IS NULL); RAISE NOTICE '%: %', v_bug_test, (v_bug_test IS NOT NULL); RAISE NOTICE '%: %', …

16 postgresql  null