データベース管理者

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 2年前休業。 複合主キーが悪い習慣であるかどうかを知り、そうでない場合は、どのシナリオを使用することが推奨されますか。 私の質問はこの記事に基づいています 複合主キーに関する部分： 悪い実践No. 6：複合主キー 現在、多くのデータベース設計者は、2つ以上のフィールドの組み合わせで定義された複合フィールドではなく、整数IDの自動生成フィールドを主キーとして使用することについて話しているため、これは論争の種です。これは現在「ベストプラクティス」として定義されており、個人的には同意する傾向があります。 ただし、これは単なる慣例であり、もちろん、DBEでは複合主キーを定義できます。これは、多くの設計者が避けられないと考えています。したがって、冗長性と同様に、複合主キーは設計上の決定事項です。 ただし、複合主キーを持つテーブルに数百万の行が含まれることが予想される場合、複合キーを制御するインデックスが、CRUD操作のパフォーマンスが非常に低下するところまで大きくなる可能性があることに注意してください。その場合、インデックスが十分にコンパクトで、一意性を維持するために必要なDBE制約を確立する単純な整数ID主キーを使用する方がはるかに優れています。

14 database-design 

インデックスの膨張に悩まされているPostgreSQLでインデックスを再作成する必要があります。作成中にインデックスを使用できるようにする必要があるため、REINDEXを使用できません。新しい名前でインデックスを再作成してから、古いインデックスを削除します。インデックスを作成するために使用されたSQLステートメントを確認して、それをコピーする方法はありますか？

14 postgresql  index 

これはDBeaver UI /構成の質問だと思いますが、スクリプト（Alt-X）を実行するとメッセージがどこにあるのかわかりません。 PGAdminIIIでは、スクリプトを実行してNOTICE出力を確認します。 DBeaverでは、同じスクリプトが[統計]タブに出力されません。しかし、これがメッセージを探すべき場所かどうかはわかりません。

14 postgresql  dbeaver 

pg_restoreを使用して、ダンプファイルでpostgres dbをロードしました。私は自分のユーザーで自分のデータベースに接続しました： sudo -u arajguru psql dump select current_user; current_user -------------- arajguru これで、新しく作成されたすべてのテーブルを確認できました。 dump=> \dt List of relations Schema | Name | Type | Owner --------+-------------------+-------+---------- public | Approvals | table | arajguru public | Approvers | table | arajguru public | Conditions | table | arajguru public | Entities …

14 postgresql 

--data-onlyand --column-insertsフラグを使用して本番サーバーから新しいdbダンプを作成したので、ステージングサーバーで復元を実行するときにデータを挿入するための挿入ステートメントの束しかありません。 pg_dump -h localhost -U adminuser --data-only --column-inserts maindb > maindb.sql 本番ダンプからデータを復元する前に、ステージングサーバーデータベースのすべてのデータを最初に削除するにはどうすればよいですか？ すべてのデータのみを削除したいので、データベースやそのすべてのものを削除して作成する必要はありません。データを削除して、新しいデータをすべて挿入したいだけです。 いくつかの理由により、データベースを削除して作成するオプションがありません。私はすべてのデータを削除して挿入するだけでよいので、これを行う方法を見つけるために必要なことは何でも、進んで進んでいきますが、最初から手助けが必要です。 このプロセスも自動化する必要があります。「本番データベースからのデータのダンプ」、「ステージングデータベースのデータの削除」、「ステージングデータベースへのデータの復元」を自動化します。「ステージングデータベースのデータの削除」の部分で助けが必要です。 PostgreSQL 9.5.2で実行しています

14 postgresql  postgresql-9.5  pg-dump 

Postgres 9.5の新しいUPSERT機能の使用に問題があります 別のテーブルからデータを集計するために使用されるテーブルがあります。複合キーは20列で構成され、そのうち10列はNULL可能です。以下に、特にNULL値を使用して、私が抱えている問題のより小さなバージョンを作成しました。 CREATE TABLE public.test_upsert ( upsert_id serial, name character varying(32) NOT NULL, status integer NOT NULL, test_field text, identifier character varying(255), count integer, CONSTRAINT upsert_id_pkey PRIMARY KEY (upsert_id), CONSTRAINT test_upsert_name_status_test_field_key UNIQUE (name, status, test_field) ); このクエリの実行は、必要に応じて機能します（最初の挿入、その後の挿入は単純にカウントを増やします）。 INSERT INTO test_upsert as tu(name,status,test_field,identifier, count) VALUES ('shaun',1,'test value','ident', 1) ON CONFLICT …

13 postgresql  null  postgresql-9.5  unique-constraint  upsert 

私はやや新しいDBAであり、かなりの量のアクティビティがあるSQL Server 2012インスタンスを管理しています。ポイントインタイムリカバリが必要なため、フルリカバリモードで実行しています。 現在、私は毎日午前5時にデータベースとログの完全バックアップを取っています。一部のログファイルは最大300 GBに膨らみ、バックアップを取ってもサイズは小さくなりません。次のようなものを実行することで、サイズを小さくすることができます。 BACKUP LOG db1 TO DISK = '\\server\share\db1_log1.trn'; DBCC ShrinkFile([db1_log], 0); BACKUP LOG db1 TO DISK = '\\server\share\db1_log2.trn'; DBCC ShrinkFile([db1_log], 0); BACKUP LOG db1 TO DISK = '\\server\share\db1_log3.trn'; DBCC ShrinkFile([db1_log], 0); バックアップファイルのLSNを確認すると、次のようなものが表示されます。 RESTORE headeronly FROM DISK = N'\\server\share\db1_log1.trn' FirstLSN: 15781000014686200001 SecondLSN: 15802000000665000001 RESTORE headeronly FROM DISK …

13 sql-server  sql-server-2012  backup  logs 

WITH句を使用してVIEWを作成したいのですが、実際には正しい構文に関する参照が見つかりません。 こんな感じ WITH TempTbl AS (SELECT ...) CREATE VIEW SomeView SELECT * FROM TempTbl そして、いくつかのWITH句を使用するための正しい構文は何ですか？ MSDNで有用なものはありません:(

13 t-sql  view 

現時点では、ヒストグラムステップを部分的にカバーする範囲述部のカーディナリティをSQL Serverがどのように評価するかを理解しようとしています。 インターネット上で、ステップ内統計値の基数推定で、私は同様の質問に出くわし、Paul Whiteはそれに対してかなり興味深い答えを出しました。 Paulの答えによれば、述語> =および>のカーディナリティーを推定するための式（この場合、少なくとも120のカーディナリティー推定モデルにのみ興味があります）は次のとおりです。 >の場合： Cardinality = EQ_ROWS + (AVG_RANGE_ROWS * (F * (DISTINCT_RANGE_ROWS - 1))) > =の場合： Cardinality = EQ_ROWS + (AVG_RANGE_ROWS * ((F * (DISTINCT_RANGE_ROWS - 1)) + 1)) TransactionDate列と '20140614'から '20140618'までの日時の範囲を使用して、範囲の述語に基づいてAdventureWorks2014データベースの[Production]。[TransactionHistory]テーブルでこれらの式の適用をテストしました。 この範囲のヒストグラムステップの統計は次のとおりです。 式に従って、次のクエリの基数を計算しました。 SELECT COUNT(1) FROM [AdventureWorks2014].[Production].[TransactionHistory] WHERE [TransactionDate] BETWEEN '20140615 00:00:00.000' AND '20140616 00:00:00.000' …

13 sql-server  sql-server-2014  optimization  query  cardinality-estimates 

SQL Server 2016インスタンスからデータベースのバックアップを作成し、2017年のインスタンスに復元して作業を行う場合。 次に、2017年のインスタンスからそのデータベースを反転してバックアップし、それを使用して2016年のインスタンスの元のバージョンを上書きできますか？

13 sql-server  backup  sql-server-2016  restore  sql-server-2017 

問題 シリアライズ可能な分離の下で、RX-Xロックを引き起こすクエリのペアがあります。ただし、拡張イベントを使用してロックの取得を監視すると、RX-Xロックの取得は表示されず、リリースされるだけです。それはどこから来たのですか？ 再現 私のテーブルは次のとおりです。 CREATE TABLE dbo.LockTest ( ID int identity, Junk char(4) ) CREATE CLUSTERED INDEX CX_LockTest --not unique! ON dbo.LockTest(ID) --preload some rows INSERT dbo.LockTest VALUES ('data'),('data'),('data') ここに私の問題のバッチがあります： SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRAN INSERT dbo.LockTest VALUES ('bleh') SELECT * FROM dbo.LockTest WHERE ID = SCOPE_IDENTITY() --ROLLBACK …

13 sql-server  locking  sql-server-2017 

physical_onlyオプションを指定してcheckdbを実行していますが、次のような複数のエラーで失敗します。 メッセージ8965、レベル16、状態1、行1 テーブルエラー：オブジェクトID 1557580587、インデックスID 1、パーティションID 72057594088456192、割り当てユニットID 72057594177454080（行データ型）。ページ（1：13282192）、スロット3、テキストID 6370769698816の行外データノードは、ページ（0：0）、スロット0で参照されますが、スキャンでは表示されませんでした。メッセージ8965、レベル16、状態1、行1 テーブルエラー：オブジェクトID 1557580587、インデックスID 1、パーティションID 72057594088456192、割り当てユニットID 72057594177454080（行データ型）。ページ（1：13282192）、スロット5、テキストID 6370769764352の行外データノードは、ページ（0：0）、スロット0で参照されますが、スキャンでは表示されませんでした。 CHECKDBは、テーブル 'TableX'（オブジェクトID 1557580587）で0の割り当てエラーと5255の一貫性エラーを検出しました。CHECKDBは、データベース 'DatabaseX'で0の割り当てエラーと5255の一貫性エラーを検出しました。repair_allow_data_lossは、DBCC CHECKDB（DWH_LAND）によって検出されたエラーの最小修復レベルです。 ただし、完全なcheckdbは成功します。 CHECKDBは、データベース 'DatabaseX'で0の割り当てエラーと0の一貫性エラーを検出しました。DBCCの実行が完了しました。DBCCがエラーメッセージを出力した場合は、システム管理者に連絡してください。 TableXには約20万行があり、クラスター化された列ストアインデックスがあります。 次のバージョンのSQL Serverを使用しています： Microsoft SQL Server 2017（RTM-CU13）（KB4466404）-14.0.3048.4 心配する必要がありますか？

13 sql-server  sql-server-2017  dbcc-checkdb 

にmax degree of parallelism設定し2、にcost threshold for parallelism設定した4 vCPU VMでMicrosoft SQL Server 2016 SP2-CU6（13.0.5292.0）を実行しています50。 朝、SELECT TOP 100クエリの推定実行プランを表示しようとすると、大量の待機が発生し、推定プランをレンダリングする操作に数分、多くの場合5〜7分の範囲で時間がかかります。繰り返しますが、これはクエリの実際の実行ではなく、推定実行プランを表示するプロセスです。 sp_WhoIsActivePAGEIOLATCH_SH待機またはLATCH_EX [ACCESS_METHODS_DATASET_PARENT]待機のいずれかが表示され、操作中にポールランダルのWaitingTasks.sqlスクリプトを実行すると、待機が表示されるCXPACKETワーカースレッドでPAGEIOLATCH_SH待機が表示されます。 *リソースの説明フィールド= exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen ワーカースレッドは、statsテーブル全体をメモリに格納しているように見えます（Paul Randalのクエリから表示されるこれらのページ番号および後続のページ番号は、statsテーブルのクラスタ化キーに戻ります）。プランが戻ってくるstatsと、さまざまなレコードが残っているだけでキャッシュからテーブルの大部分が失われた後でも（同様のクエリからのシーク操作のためにプルされたと仮定します）、基本的に1日の残りの時間は瞬時です。 クエリが実際にSCAN演算子を使用するプランで実行されている場合、この初期動作を期待しますが、上記のリンクされたプランに示されているように、SEEKオペレーターに到達するためだけに実行プランを評価するときにこれを行うのはなぜですか？ここでのパフォーマンスを向上させるために何ができますか（営業時間前にこのステートメントを実行してデータを適切にキャッシュする以外に）。一対のカバリングインデックスが有益であると考えていますが、実際に動作の変更を保証しますか？ここで、ストレージとメンテナンスウィンドウの制限内で作業する必要があります。クエリ自体はベンダーソリューションから生成されるため、この時点で他の提案（より良いインデックス付け以外）を歓迎します。

13 sql-server  performance  sql-server-2016 

ディスク（回転メディアだけでなく、非回転メディア[SSD、NVMeなど]を含むように大まかに言います）ドライブは、基礎となるフォーマットとハードウェアで進化し続けています。これの一部は、512バイトの物理セクターサイズから4kの物理セクターサイズへの「拡張」であり、ディスク上のレイアウト（512n、512e、4kn）を変更します。 この次の進化は、8kの物理セクターサイズを使用することです。これは、一部のメーカーが生産と生産のセットアップを開始しています。この次のステップを考えると、8kセクターサイズのディスクはWindowsでサポートされていますか？SQL Serverはセクターサイズを考慮しますか？

13 sql-server  hardware 

新しいサーバーと更新されたバージョンのMicrosoft SQL Serverを使用してテスト環境をアップグレードしていますが、問題が発生しています。 新しいサーバーでは、一部のストアドプロシージャを実行すると、古いコードに「オブジェクトが閉じられているときは操作が許可されません」が表示されます。このメッセージは古いサーバーには表示されませんでした。追跡するSET NOCOUNT ON;と、ストアドプロシージャに追加することで問題を解決できます。 データベースのデフォルトを調べましたが、デフォルトに関連する異なる設定（SQL Server 2008とSQL Server 2014）はありませんでした。 SET NOCOUNT ON1000のストアドプロシージャに追加する必要なく、これをグローバルに解決するには、どの設定を検討する必要がありますか？

13 sql-server  sql-server-2008  sql-server-2014  sp-configure