データベース管理者

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

1
PostgreSQL / PostGIS 9.6で複合インデックスが壊れました
PostgreSQL 9.2では、地理(postGIS)タイプと整数の両方を複合インデックスとして持つインデックスを問題なく作成できました。しかし、現在(9.6)はインデックスの作成に不満を示しており、それが提供するヒントを理解できません。 列とデータはすべて適切に作成されていますが、Postgresは作成インデックスについて不平を言っています。 ERROR: data type integer has no default operator class for access method "gist" HINT: You must specify an operator class for the index or define a default operator class for the data type. ********** Error********** ERROR: data type integer has no default operator class for access method …

1
PostgreSQL 8.3でのバックアップおよびPostgreSQL 9.4での復元後にデータベースサイズが縮小
私は、pg_dumpPostgreSQL 8.3サーバーでホストしているJIRAデータベースで実行しました。データベース後のサイズvacuum fullだった217132652(約207メガバイト)。 次に、次のコマンドを使用して、JIRAデータベースをPostgreSQL 9.4サーバーに復元しました。 $ psql -X -v ON_ERROR_STOP=1 -d jira2 -U jira -h localhost < jiradb2017_03_12.sql 私はを使用して以来、エラーが発生すると復元が終了すると思いON_ERROR_STOP=1ますが、SQLスクリプトは正常に終了しました(データの復元に関連しないいくつかの警告にもかかわらず)。 最終的に、サイズが158019348(約151 MB)のデータベースができました。 だから、ここの話は何ですか?データベースが正常に復元され、PostgreSQLがストレージ(バージョン8.3から9.4の間)を最適化し、スペースをより効率的に使用していると仮定できますか?

5
ウィンドウ関数を使用したサブクエリの最適化
私のパフォーマンスチューニングのスキルを十分に感じるように見えることはありませんようがあれば、私はいつも疑問に思うより多くの私はいくつかのクエリに対して実行することができ、最適化が。この質問が関係する状況は、サブクエリ内にネストされたウィンドウ化MAX関数です。 私が調べているデータは、より大きなセットのさまざまなグループでの一連のトランザクションです。重要なフィールドは4つあります。トランザクションの一意のID、トランザクションのバッチのグループID、およびそれぞれの一意のトランザクションまたはトランザクションのグループに関連付けられた日付です。ほとんどの場合、グループの日付はバッチの最大一意のトランザクションの日付と一致しますが、システムで手動調整が行われ、グループのトランザクションの日付がキャプチャされた後に一意の日付の操作が発生する場合があります。この手動編集では、グループの日付は意図的に調整されません。 このクエリで特定するのは、一意の日付がグループの日付の後にあるレコードです。次のサンプルクエリは、私のシナリオにほぼ相当するものを構築し、SELECTステートメントは探しているレコードを返しますが、このソリューションに最も効率的な方法でアプローチしていますか?これは、ファクトテーブルの読み込み中にレコードが上位9桁の数を数えるため、実行に時間がかかりますが、ほとんどの場合、サブクエリを無視することで、ここにもっと良いアプローチがあるかどうか疑問に思います。インデックスは既に用意されていると確信しているので、インデックスについては心配していません。私が探しているのは、同じことを実現するが、さらに効率的な代替のクエリアプローチです。どんなフィードバックでも大歓迎です。 CREATE TABLE #Example ( UniqueID INT IDENTITY(1,1) , GroupID INT , GroupDate DATETIME , UniqueDate DATETIME ) CREATE CLUSTERED INDEX [CX_1] ON [#Example] ( [UniqueID] ASC ) SET NOCOUNT ON --Populate some test data DECLARE @i INT = 0, @j INT = 5, @UniqueDate DATETIME, @GroupDate DATETIME …

2
別々のデータベース間の関係は悪い習慣ですか?
複数のデータベースを持つクライアントを使用しています。レベルデータベース(アプリケーション固有のDB)masterからの関係を持ついくつかのレベルデータベースがありますinstance。fromからinstancetoへの関係masterは、のテーブルへの主キーを表す整数値ですmaster。のビューとストアドプロシージャは、これらのストアドキーを介してinstancesデータをロードするように設定masterされています。 明らかに、実際の参照整合性はありませんが、それは悪い習慣なのinstanceでしょうか、それともデータベースの読み取り専用テーブルにデータを常駐させるべきなのでしょうか。

1
奇妙な密度はサンプリングされた統計をもたらす
NCインデックスは、サンプリングとフルスキャンで推定すると、まったく異なる統計分布を取得します。サンプリングされたものは、奇妙な密度ベクトルを持っています。その結果、実行計画が不十分になります。 非クラスター化インデックスでサポートされているnull以外のFK列を含む、約2,700万行のテーブルがあります。テーブルは主キーでクラスター化されます。どちらの列もvarcharです。 FKカラムのフルスキャン統計更新により、通常の密度ベクトルが得られます。 All density Average Length Columns 6,181983E-08 45,99747 INSTANCEELEMENTID 3,615442E-08 95,26874 INSTANCEELEMENTID, ID つまり、INSTANCELEMENTID結合する個別の行ごとに約1.7行を読み取ることが期待されています。 ヒストグラムの一般的なビンは次のようになります。 RANGE_HI_KEY RANGE_ROWS EQ_ROWS DISTINCT_RANGE_ROWS AVG_RANGE_ROWS FOOBAR 133053 10 71366 1,679318 ただし、サンプルの更新を行う場合(このテーブルのデフォルトのサンプル番号は230k行です)、奇妙なことが起こります。 4,773657E-06 45,99596 INSTANCEELEMENTID 3,702179E-08 95,30183 INSTANCEELEMENTID, ID 上の密度INSTANCEELEMENTIDは2桁大きくなりました。(ただし、両方のカラムの密度はかなり許容できる値に推定されています)。 ヒストグラムの典型的なビンは次のようになります。 RANGE_HI_KEY RANGE_ROWS EQ_ROWS DISTINCT_RANGE_ROWS AVG_RANGE_ROWS FOOBAR 143870,4 766,2573 1247 115,3596 ZOTZOT 131560,7 1 …

5
コードのブロックを選択するためのショートカット/スニペット
Windows 10でSQL Server Management Studio 2016を使用しています。実行するコードを選択するためにShift / Ctrl + Up / Down / Right / Leftキーを使用するのにうんざりしています。空白行で他のコードから分離されたコードのブロックを選択するショートカット/スニペットがあるかどうか疑問に思っていますか? 次にコード例を示します。 select * from tab1 select * from tab2 select * from tab3 たとえば、カーソルが中央のブロック内にあり、中央のブロックを選択するための最良の方法は何ですか?
8 ssms 

4
「AlwaysOn」は常に「Always On」ではありませんか?
Windowsフェールオーバークラスターを作成し、SQL Serverの2つのインスタンスをSQL Serverフェールオーバークラスターのノードとして追加しました。 SQL構成マネージャーで「AlwaysOn可用性グループ」を使用するようにサーバーを設定します。 フェイルオーバーをテストするために、長いクエリをロードして実行し、次にFailover Cluster Managerを使用してアクティブノードを停止し、アクティブノードのクラスターサービスを停止しました。 クエリは接続なしで壊れ、ノードがドレインされて新しいノードが引き継ぐ前に、サーバーは約20秒間使用不可と表示されました。 私はこれを間違っていましたか?接続がほとんどまたはまったく失われないように、これをどのように構成する必要がありますか? AlwaysOnは常にオンではありませんか?

2
pg_trigger_depth()は、トリガーのカスケード(再帰)を防止するために使用するのは悪いですか?
pg_trigger_depth() = 0トリガーのカスケード(再帰)を防止するときに(デバッグ以外の目的で)使用するのが悪いのはなぜですか? 誰かがなぜそれが悪いのかを示すコードを提供できますか? 複数のトリガーが同じデータで同時に機能している場合、トリガーを使用して停止する条件pg_trigger_depth() = 0は、2番目に機能するトリガーを停止するためだと思います。 私はそれがこの(私の)質問に対する良い解決策になると思いましたが、そうでないと言われました: トリガー内に、更新または挿入がトリガーから来たかどうかを確認する方法はありますか? それは良い質問をするだろうと思った。 これはソリューションとしてここに提供されています: PostgreSQLの再帰トリガーを防止する Postgres 9.3ドキュメント: https://www.postgresql.org/docs/9.3/static/functions-info.html

2
これがBIGINT colでシークするのに、追加の定数スキャン、計算スカラー、ネストされたループ演算子があるのはなぜですか?
一部のクエリの実際の実行計画を見ると、WHERE句で使用されているリテラル定数が、スカラー計算と定数スキャンのネストされたチェーンとして表示されていることに気づきました。 これを再現するには、次の表を使用します CREATE TABLE Table1 ( [col1] [bigint] NOT NULL, [col2] [varchar](50) NULL, [col3] [char](200) NULL ) CREATE NONCLUSTERED INDEX IX_Table1 ON Table1 (col1 ASC) その中にいくつかのデータがあります: INSERT INTO Table1(col1) VALUES (1),(2),(3), (-9223372036854775808), (9223372036854775807), (2147483647),(-2147483648) 次の(ナンセンス)クエリを実行すると: SELECT a.col1, a.col2 FROM Table1 a, Table1 b WHERE b.col1 > 2147483648 インデックスシークとスカラー計算(定数から)の結果で、ネストされたループの描画を行うことがわかります。 リテラルがmaxintよりも大きいことに注意してください。それは書くのに役立ちますCAST(2147483648 as …

3
新しく作成された列に挿入することはできません
私はこのような簡単なテストテーブルを持っています: CREATE TABLE MyTable (x INT); トランザクション内で、列を追加してから、新しく作成した列に挿入しようとしています。 BEGIN TRANSACTION; PRINT 'Adding column, ''SupplementalDividends'', to MyTable table.'; ALTER TABLE MyTable ADD SupplementalDividends DECIMAL(18,6); PRINT 'Column added successfully....'; PRINT 'Ready to INSERT into MyTable ...'; INSERT INTO MyTable (x, SupplementalDividends) VALUES (1, 3.2); PRINT '**** CHANGES COMPLETE -- COMMITTING.'; COMMIT TRANSACTION; 上記のコードを実行すると、問題はエラーメッセージになります。 …

1
JSONオブジェクトからのUNIQUE制約の作成
2つのフィールド(idとdata(json))しか持たないテーブルpeoplesの例をいくつか見てみましょう。 SELECT data FROM peoples ; {"name": "Adam","pos":"DBA","age":22 } {"name": "Alice","pos":"Security","age":33 } {"name": "Bob","pos":"Manager","age":42 } 一意である必要がある「pos」フィールドの制約を作成したい。JSON制約についてインターネットで検索しましたが、結果はありませんでした。 この問題をどのように処理できますか?

1
フォルダー内の複数の.DTSXパッケージファイルのPackageFormatVersionを決定する
Kenneth Fisherが、私のSSISパッケージとはどのSQLバージョンであるかを判断する方法についてブログ投稿しました。2015年4月。 これにはPackageFormatVersion、XMLメタデータで見つかったSSISパッケージのどれにSQLバージョンがマップされているかのテーブルがあります。これは、1つの個別のパッケージを確認するときに役立ちます。 約100のSSIS .DTSXパッケージのフォルダーがあり、それらのSQLバージョンをすべて知る必要があります。 フォルダー(ファイルシステム)内のPackageFormatVersion複数の.DTSXパッケージの何(つまり、SQLバージョン)を一括して決定することができますか? 最終的な目標は、現在ソース管理システムが存在しないため、これらのパッケージを取得するために取得および実装する適切なTFSバージョンを決定することです。Kennethが提示する表は、この質問に答えるのに役立ちますが、最初に、SQLバージョンのパッケージを確認する必要があります。 BIDSもSSDTもインストールされていないとします。 必要な出力が次のようなものであると想定します。ここで、pipeは新しい列を指定します。 PackageFilename | PackageFormatVersion -------------------------------------- Package1.dtsx | 3 Package2.dtsx | 4 PowerShell、TSQL、ディレクトリ構造をクロールできるサードパーティツール、またはその他のツールを歓迎します。

4
トリガーでSELECT * okです。または私はトラブルを求めていますか?
私は仕事で議論に巻き込まれ、見落としている可能性のある落とし穴についてアドバイスが必要です。 削除されたレコードを監査テーブルにコピーするためにトリガーが使用されるシナリオを想像してみてください。トリガーはSELECT *を使用します。誰もが指さして叫び、これがどれほど悪いかを私たちに教えます。 ただし、メインテーブルの構造に変更が加えられ、監査テーブルが見落とされた場合、トリガーによってエラーが生成され、監査テーブルにも変更が必要であることを通知します。 このエラーは、DEVサーバーでのテスト中に検出されます。ただし、プロダクションがDEVと一致することを確認する必要があるため、プロダクションシステムでSELECT *を許可します(トリガーのみ)。 だから私の質問は:私はSELECT *を削除するようにプッシュされていますが、この性質の開発エラー、アイデア、またはこのベストプラクティスを自動的にキャプチャしていることを確認する他の方法がわかりませんか? 以下の例をまとめました: --Create Test Table CREATE TABLE dbo.Test(ID INT IDENTITY(1,1), Person VARCHAR(255)) --Create Test Audit Table CREATE TABLE dbo.TestAudit(AuditID INT IDENTITY(1,1),ID INT, Person VARCHAR(255)) --Create Trigger on Test CREATE TRIGGER [dbo].[trTestDelete] ON [dbo].[Test] AFTER DELETE NOT FOR REPLICATION AS BEGIN SET NOCOUNT ON; …

2
自己参照(階層)テーブルからツリー構造を取得できますか?
次のような階層テーブルがあるとします。 CREATE TABLE [dbo].[btree] ( id INT PRIMARY KEY , parent_id INT REFERENCES [dbo].[btree] ([id]) , name NVARCHAR(20) ); ツリー構造全体を取得したいのですが。 たとえば、次のデータを使用します。 INSERT INTO [btree] VALUES (1, null, '1 Root'); INSERT INTO [btree] VALUES (2, 1, '1.1 Group'); INSERT INTO [btree] VALUES (3, 1, '1.2 Group'); INSERT INTO [btree] VALUES (4, …

2
SQL Server 2016 Standard Editionはテーブルのパーティション分割をサポートしていますか?
SQL Server 2008 Enterprise EditionをSQL Server 2016 Standard Editionにアップグレードしたい。ただし、1つのデータベースは、複数のファイルグループにまたがるテーブルパーティションを使用します(大きなログテーブルで使用され、毎日がパーティションです)。 私はで見るSQL Serverの2016年のためのエディションとサポートされる機能、それはスタンダード版がサポートしていることを言うことは、「RDBMSスケーラビリティとパフォーマンス」の下にテーブルとインデックスのパーティションを、それがないではないサポートするパーティション表の並列処理を。 私がこれの結果を完全に理解しているかどうかはわかりません。 私の場合、それは正確に何を意味し、データベースのパフォーマンスにどのように影響しますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.