データベース管理者

データベースのスキルを向上させ、コミュニティの他の人から学びたいデータベースの専門家向けのQ&A

2
これらのツールはまだ有効ですか？
私はBrent Ozar（https://youtu.be/U_Kle3gKaHc）によって行われた7歳のウェビナーを見ていましたが、そのときにいくつかのアイテムが推奨されていると聞きました。 SQLDiagユーティリティ。 SQLNexus。 PALツール。 データベース調整アドバイザー/ウィザード。 BPA（ベストプラクティスアナライザー）。 SQL Serverポリシーベースの管理。 それらのすべてがまだ使用/検討されているか、またはそれらを置き換える新しい何かがありますか？
10 sql-server  tools 
3
SQL Serverは、バッファキャッシュに十分なスペースがないクエリのデータをどのように処理しますか？
私の質問は、SQL Serverが、利用可能な領域よりも多くのデータをバッファキャッシュにプルする必要があるクエリをどのように処理するかです。このクエリには複数の結合が含まれているため、結果セットはこのフォーマットですでにディスク上に存在せず、結果をコンパイルする必要があります。ただし、コンパイル後でも、バッファキャッシュで使用可能な領域よりも多くの領域が必要です。 例を挙げましょう。合計6GBの利用可能なバッファキャッシュスペースを持つSQL Serverインスタンスがあるとします。7GBのデータを読み取る複数の結合を使用してクエリを実行しますが、SQL Serverはこの要求にどのように応答できますか？tempdbにデータを一時的に保存しますか？失敗しますか？ディスクからデータを読み取り、一度にセグメントをコンパイルするだけですか？ さらに、7GBの合計データを返そうとするとどうなりますか？SQL Serverがデータを処理する方法は変わりますか？ 私はこれに対処するいくつかの方法をすでに知っていますが、SQL Serverがこのように実行されたときに、SQL Serverがこの要求を内部的に処理する方法に興味があります。 また、この情報はどこかにあると思いますが、見つけるのに失敗しました。
3
非永続計算列SQLサーバーでの非クラスター化インデックスの作成
SQL Serverが非永続計算列を実際に格納する方法に関するドキュメントを見つけるのに苦労しています。 次の例を見てください。 --SCHEMA CREATE TABLE dbo.Invoice ( InvoiceID INT IDENTITY(1, 1) PRIMARY KEY, CustomerID INT FOREIGN KEY REFERENCES dbo.Customer(CustomerID), InvoiceStatus NVARCHAR(50) NOT NULL, InvoiceStatusID AS CASE InvoiceStatus WHEN 'Sent' THEN 1 WHEN 'Complete' THEN 2 WHEN 'Received' THEN 3 END ) GO --INDEX CREATE NONCLUSTERED INDEX IX_Invoice ON Invoice …
3
非IT担当者向けのデータベースステージング環境
現在、データベースステージング環境をIT部門に提案しています。アイデアは、私のような非IT担当者（公共事業データアナリスト）がソリューションをテストする場所を持ち、自分で実際の環境に実装するか、必要に応じてITに実装を依頼するというものです。この環境が有益である理由/シナリオはいくつかあります。 私は（私たちのライブデータベース環境でいくつかの基本的なデータベース権限を持っているcreate table、create viewなど）。スキーマの変更は約1週間に1回行いますが、これらの変更を実際の環境でテストして実装するのは、私には異常です。データベースには無数の依存関係があるため、問題が発生した場合は悲惨なことになる可能性があります。むしろ、別の環境で事前にテストしておいたほうがいいです。 私のような、より高度な権限の一部はありませんcreate triggerか、create functionライブデータベース内を。これは問題ありませんが、トリガーや関数によって解決できる問題がいくつかあります。いくつかのアイデアを開発およびテストできるように、ステージング環境でこれらの権限を付与することを提案し、それらが機能する場合は、ITがそれらをライブ環境に実装することを提案します。 一般に、私のIT部門には、ソリューションを開発するための時間やリソースがありません。とても簡単です。ですから、私が自分でレッグワークを行うことができれば、私の問題ははるかに解決されるでしょう。 「非IT担当者向けのステージング環境」は、私にとっては十分に健全なアプローチのように思えますが、正直に言って、考えをまとめただけです。IT /データベースの世界でこれがどのように一般的に行われるのか私にはわかりません。 このシナリオに当てはまる確立されたIT /データベースプラクティスはありますか？（非IT担当者向けのデータベースステージング環境を提案するときに、私は正しい軌道に乗っていますか？）
1
クロスデータベース証明書を使用する場合のトリガーの権限
私のデータベース（SQL Server 2008 R2）の特定のデータベースへのアクセスを制御するために、クロスデータベース証明書（Erland Sommarskogが説明）を使用しています。 私はデータベースBのテーブルを更新するデータベースAのストアドプロシージャを持っています。これは、これまで、db Aのさまざまなストアドプロシージャとdb Bのテーブルで常に機能していました。db Bのテーブルを更新しようとしていますが、テーブルにトリガーがあります。このトリガーは、db Bの別のテーブルに追加のデータを挿入しています。次のエラーが発生します。 メッセージ916、レベル14、状態1、プロシージャtable_trigger、行11サーバープリンシパル "sql \ login"は、現在のセキュリティコンテキストではデータベース "B"にアクセスできません。 証明書に関連付けられているデータベースBユーザーに、他のテーブルに挿入する挿入アクセス許可を付与しようとしましたが、エラーは解決しませんでした。トリガーを変更する以外にオプションはありWITH EXECUTE AS OWNERますか？ 問題を再現するDDLは次のとおりです。 CREATE LOGIN [GuggTest] WITH PASSWORD=N'abcd', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF CREATE DATABASE A; CREATE DATABASE B; USE A; CREATE TABLE dbo.SPtoUpdate ( ID INT , ILoveFishing VARCHAR(255) ); INSERT INTO dbo.SPtoUpdate ( …
3
MAXTRANSFERSIZEおよびCHECKSUMが使用されている場合、TDE対応データベースを復元できません
更新：@AmitBanerjee -Microsoft SQL Server製品グループのシニアプログラムマネージャーは、MSが問題であることを調査することを確認しました。 TDEを有効にし、MAXTRANSFERSIZE> 65536 を使用してSQL Server 2016で作成したバックアップを復元するときに問題が発生しましたか（私の場合、TDEデータベースを圧縮できるように65537を選択しました）CHECKSUM。 以下は再現です： --- create database create database test_restore go -- create table create table test_kin (fname char(10)) go -- Enable TDE use master GO CREATE CERTIFICATE test_restore WITH SUBJECT = 'test_restore_cert' GO SELECT name, pvt_key_encryption_type_desc, * FROM sys.certificates WHERE name = 'test_restore' …
3
指定されたネットワーク名は使用できなくなりました
データベースにアクセスするアプリケーションがあります（SQL Server 2014 Enterprise Edition）。アプリケーションは、データベースにアクセスするためのストアドプロシージャを呼び出します。最近、次のエラーの送信を開始してアプリケーションを停止するまで、すべてが正常に機能していました。アプリを再起動すると問題が一時的に解決しますが、同じエラーが発生します。 エラー：サーバーから結果を受信するときに、トランスポートレベルのエラーが発生しました。（プロバイダー：TCPプロバイダー、エラー：0-指定されたネットワーク名は使用できません。） 私は多くの調査を行いましたが、それらのほとんどはネットワークの問題として指摘していますが、実際に問題を解決するためのものが見つかりませんでした。この問題を解決するためにデータベース側で行う必要がある変更を誰かが知っていますか？私は提案を高く評価します。
1
COALESCEを使用して主キーをIDENTITYから永続化された計算列に変更する
モノリシックデータベースからアプリケーションを分離するために、さまざまなテーブルのINT IDENTITY列を、COALESCEを使用するPERSISTED計算列に変更しようとしました。基本的に、分離アプリケーションには、多くのアプリケーションで共有される共通データのデータベースを更新しながら、コードやプロシージャを変更することなく、既存のアプリケーションがこれらのテーブルにデータを作成できる機能が必要です。 したがって、基本的に、列の定義から移動しました。 PkId INT IDENTITY(1,1) PRIMARY KEY に; PkId AS AS COALESCE(old_id, external_id, new_id) PERSISTED NOT NULL, old_id INT NULL, -- Values here are from existing records of PkId before table change external_id INT NULL, new_id INT IDENTITY(2000000,1) NOT NULL すべての場合でPkIdは主キーでもあり、1つを除いてすべてクラスタ化されています。すべてのテーブルには、以前と同じ外部キーとインデックスがあります。本質的に、新しい形式では、PkIdを分離されたアプリケーションから（external_idとして）提供できますが、PkIdをIDENTITY列の値にすることもできるため、SCOPE_IDENTITYおよび@@ IDENTITYを使用してIDENTITY列に依存する既存のコードを許可できます。以前と同じように動作します。 私たちが抱えていた問題は、許容範囲内で実行されていたクエリが2つ出てきて、完全に機能しなくなったことです。これらのクエリで使用される生成されたクエリプランは、以前のクエリプランとは異なります。 新しい列がPRIMARY KEY、以前と同じデータ型、およびPERSISTEDであることを考えると、クエリとクエリプランは以前と同じように動作するはずです。COMPUTED PERSISTED INT PkIdは、SQL Serverが実行プランを生成する方法に関して、本質的に明示的なINT定義と同じように動作する必要がありますか？あなたが見ることができるこのアプローチの他の可能性のある問題はありますか？ …
1
SQL Server Express Editionの制限の克服
Microsoft SQL Server 2014 Expressエディションのデータベースサイズの制限は10 GBです。さて、それは単一のインスタンスのためのものですか、それともエディションで許可される全体的なサイズですか？それとも、各データベースが10GB未満であれば、エディションを使用してデータベースをいくつでも持つことができるということですか？
1
SQL Server-更新ステートメントでウィンドウ関数が許可されないのはなぜですか？
以下のようなupdateステートメントを実行すると、エラーメッセージが表示され、 ウィンドウ関数は、SELECT句またはORDER BY句でのみ使用できます。 UPDATE dbo.Dim_Chart_of_Account SET Account_Order = LAG([Account_Order]) OVER (ORDER BY [Account_SKey]) これは、以下のような更新可能なcteを使用して簡単に回避できることを知っています WITH my_cte AS ( SELECT [Account_Order], LAG([Account_Order]) OVER (ORDER BY [Account_SKey]) AS acc_order_lag FROM Dim_Chart_of_Account ) UPDATE my_cte SET [Account_Order] = acc_order_lag 私の質問は、これがupdateステートメントで許可されていない理由はありますか？回避策として更新可能なcteを使用しないようにすべきですか？ 私の懸念は、更新ステートメントでウィンドウ関数を使用するときに問題があるため、これが許容できる方法であるのか、それとも避けるべきなのかを理解したいのです。
3
リレーショナルデータベースの整合性の制約-見落とすべきですか？
大規模なクエリを高速化し、より良い結果を得るには、リレーショナルデータベースで（FOREIGN KEY制約定義を介して）関係の強制を取り除く方が良いと言うので、私は私が働いている会社の開発者と恒久的に話し合っています。パフォーマンス。 検討中のプラットフォームはMySQL 5.xであり、FOREIGN KEYがセットアップされておらず、関連するテーブルの一部のPRIMARY KEY制約が欠けていても、少なくとも私にとっては妥当ではありません。多分彼らは正しいのですが、私は間違っていますが、私はこの状況について議論するのに十分な議論がありません。 これは3年間、推奨されるアプローチでした。私はこの会社の新人です（わずか1か月）が、製品が「機能する」ため、データベースを拡張するのにためらいがあります。それにもかかわらず、最初に気付いたのは、1ページの読み込みに1分（はい、60秒！）かかっていることです。 現在の状況の背後にある主張の1つは、「非正規化された」データベースは正規化されたデータベースよりも速いということですが、私はそれが本当だとは思いません。 関連するクエリのほとんどにJOIN操作が含まれているため、大量のデータがあると非常に遅くなります（データベースには数百万の行が含まれます）。 通常、「CRUD」操作の処理は、アプリケーションプログラムコードレベルで実装されます。たとえば、FROMからデータを削除するには、次のようにしましょうTableA： との行の間に何らかの関係があるかどうかをその場で最初に確認する必要がTableAありますTableB。 上記の関係が「検出」された場合、アプリプログラムコードは関連する行の削除を許可しませんが、 何らかの理由でアプリのプログラムコードが失敗した場合、関連する行とテーブルに関係があるかどうかに関係なく、DELETE操作は「成功」します。 質問 議論を深めるために、私が良い、正確で確固とした答えを詳しく説明するのを手伝っていただけませんか？ 注：たぶん、このようなものは以前に尋ねられた（そして答えられた）かもしれませんが、Googleを使用して何も見つけることができませんでした。
3
統計の自動更新をFalseに設定する理由
幅広い買収プロジェクトの一環として、SQL Serverのインスタンスを約20継承しました。私はパフォーマンスを評価している最中であり、メンテナンスプランの実装方法が気に入らない。 毎日のブランケットインデックスの再構築（これを処理できます）と、統計の毎日の手動更新が表示されています。 データベースの約半分は、統計の自動更新= Falseに設定されています。理由は、「パフォーマンスの問題」を減らすことだと言われていること以外は明確ではありません... 私は常にこれをTrueに設定するベストプラクティスを考え、これに取り組みました。この設定がTrueの場合、手動更新は必要ないと感じました。私が間違っている？ 誰もがこれをFalseに設定することの利点を説明できますが、代わりに毎日手動で更新することはできますか？ 一部のデータベースはトランザクション性が高い（1日あたり数百万の挿入、削除、更新）データベースもあります。その他のデータベースはトランザクション率が低く、一部はすべて読み取り専用です。Auto Update設定がFalseに設定されているのに、韻や理由はありません。宝くじのようです。
2
SQL Serverサンプルの統計更新では、昇順キー列で最も高いRANGE_HI_KEYが欠落しています
統計のサンプリングがどのように機能するか、およびサンプリングされた統計の更新に対して以下の動作が期待されるかどうかを理解しようとしています。 数十億行の日付で分割された大きなテーブルがあります。分割日は前の営業日であり、昇順のキーです。前日のデータのみをこのテーブルにロードします。 データの読み込みは夜間に実行されるため、4月8日金曜日に7日目のデータを読み込みました。 実行するたびに、統計を更新しますが、ではなくサンプルを使用しFULLSCANます。 たぶん私はナイーブですが、SQL Serverが範囲内の最高のキーと最低のキーを識別して、正確な範囲サンプルを確実に取得することを期待していました。この記事によると： 最初のバケットの場合、下限は、ヒストグラムが生成される列の最小値です。 ただし、最後のバケット/最大値については言及していません。 サンプリングされた統計の更新が8日の朝に行われたため、サンプルは表（7日）で最も高い値を逃しました。 前日のデータに対して多くのクエリを実行したため、カーディナリティの推定が不正確になり、多くのクエリがタイムアウトしました。 SQL Serverはそのキーの最高値を特定し、それを最大値として使用するべきではありませんRANGE_HI_KEYか？それとも、これを使用しない場合の更新の制限の1つにすぎFULLSCANませんか？ バージョンSQL Server 2012 SP2-CU7。OPENQUERYSQL ServerとOracleの間のリンクサーバークエリの数値を切り捨てていたSP3の動作が変更されたため、現在アップグレードできません。
2
SQL Serverがすべてのメモリを使用していない
SQL Server 2014で、最大メモリを6GBに設定しています（物理メモリは8GB）。 ターゲットサーバのメモリは、時には6ギガバイトで、その後、バックに落ちるの合計サーバーメモリ（約5.3ギガバイト、6ギガバイトに達することはありません）。私が使用committed_kbをしてsys.dm_os_sys_info SQL Serverが使用するメモリをチェックします。 sys.dm_os_buffer_descriptorsを監視すると、ページがキャッシュから削除されていることがわかりますが、残りのメモリは700MBです。メモリが必要ない場合、ページがキャッシュから削除されるという事実をどのように説明しますか？SQL Serverは、メモリが必要な場合にのみページを削除すると思います。 割り当て解除された一時テーブルは、このサーバーでは問題になりません。私のPLEは3632です。プロシージャキャッシュは2182 MBです。 メモリが残っていない場合にのみページがドロップされると思いますが、700MBの空き容量があるか、これを誤解していますか？ 誰かがこの動作を説明してみてください。 SQL Serverもディスクから読み取っているので、必要なすべてのページがメモリにあるとは限らないと思います。 さらに調査を行ったところ、ディスクからメモリに大量のページを読み取り、読み取り中にタスクマネージャに何かがあったことに気づきました。 使用中のメモリは7.0GB-> 7.2GB-> 7.0GB-> 7.2GB-> ... Sqlservr.exeは5.3GB-> 5.5GB-> 5.3GB-> 5.5GB-> ... これは、Windowsがsqlservr.exeを6GBに拡張できないようです。 Shankyから提供されたクエリを実行しました。 select (physical_memory_in_use_kb/1024) Physical_Memory_usedby_Sqlserver_MB, (locked_page_allocations_kb/1024 )Locked_pages_used_Sqlserver_MB, (Virtual_address_committed_kb/1024 )Total_Memory_in_MB,--RAM+ Pagefile process_physical_memory_low, process_virtual_memory_low from sys. dm_os_process_memory これにより、次の結果が得られました。 Physical_Memory_usedby_Sqlserver_MB: 5247 Locked_pages_used_Sqlserver_MB: 0 Total_Memory_in_MB: 5625 process_physical_memory_low: 0 process_virtual_memory_low: …
1
インメモリテーブルのパフォーマンスがディスクベースのテーブルよりも悪い
SQL Server 2014に次のようなテーブルがあります。 CREATE TABLE dbo.MyTable ( [id1] [bigint] NOT NULL, [id2] [bigint] NOT NULL, [col1] [int] NOT NULL default(0), [col2] [int] NOT NULL default(0) ) （id1、id2）はPKです。基本的に、id1は結果のセット（id2、col1、col2）をグループ化する識別子であり、pkはid2です。 私のボトルネックである既存のディスクベースのテーブルを取り除くために、メモリ内のテーブルを使用しようとしています。 テーブル内のデータが書き込まれます->読み取り->一度削除されます。 各id1値には、数千（数十/数十万）のid2があります。 データは、非常に短時間、たとえば20秒の間、テーブルに保存されます。 このテーブルで実行されるクエリは次のとおりです。 -- INSERT (can vary from 10s to 10,000s of records): INSERT INTO MyTable SELECT @fixedValue, id2, col1, col2 …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.