データベース管理者

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

2
charindex関数の長い文字列を分割/保存する最速の方法
1 TBの数字列があります。12文字の数字のシーケンスが与えられた場合、元の文字列（charindex関数）でこのシーケンスの開始位置を取得します。 SQL Serverを使用して1GBの文字列と9桁の部分文字列でこれをテストし、文字列をとして保存しましたvarchar(max)。Charindex10秒かかります。1 GBの文字列を900バイトのオーバーラップチャンクに分割し、バイナリ照合でchunkofstringを使用してテーブル（StartPositionOfChunk、Chunkofstring）を作成すると、インデックス作成に1秒未満かかります。10GB、10桁の部分文字列の後者の方法では、charindexが1.5分に上昇します。より高速な保存方法を見つけたいのですが。 例 数字列：0123456789-検索する部分文字列345 charindex（ '345'、 '0123456789'）は4を与えます 方法1：これを、1つの列で構成されるSQL Serverテーブルstrtableに格納しcolstr、実行できます。 select charindex('345',colstr) from strtable 方法2：または、元の文字列を分割することにより、テーブルstrtable2（pos、colstr1）を作成できます。2; 123 | 3; 234 asoそして、クエリを select pos from strtable2 where colstr1='345' 方法3：元の文字列をより大きなチャンクに分割することで、テーブルstrtable2（pos2、colstr2）を作成できます1; 01234 | 4; 34567 | 7、6789、次いで select pos2+charindex('345',colstr2) from strtable2 where colstr2 like '%345%' 最初の方法が最も遅いです。 2番目の方法では、データベースのストレージサイズが大きくなります。 方法3：バイナリ照合でcolstr2の長さを900バイトに設定し、この列にインデックスを作成すると、1GBの文字列と9桁の部分文字列の検索に1秒かかります。10GBの文字列と10桁の部分文字列の場合、istには90秒かかります。 これをより速くする他のアイデア（おそらく、文字列を使用することによって、文字列は長整数の数字で構成されます...）？ 検索では常に、1 TBの数字列の12桁の部分文字列が検索されます。SQLServer 2017 …
1
この列で自動作成された統計が空になるのはなぜですか？
情報 私の質問は、ヒープである適度に大きなテーブル（約40GBのデータスペース）に関するもの です（残念ながら、アプリケーションの所有者はテーブルにクラスター化インデックスを追加できません） ID列（ID）に自動作成された統計が作成されましたが、空です。 統計の自動作成と統計の自動更新がオンになっています テーブルで変更が行われました 更新されている他の（自動作成された）統計があります インデックスによって作成された同じ列に別の統計があります（重複） ビルド：12.0.5546 重複する統計が更新されています： 実際の質問 私の理解では、まったく同じ列（重複）に2つの統計がある場合でも、すべての統計を使用でき、変更が追跡されるので、なぜこの統計が空のままなのですか？ 統計情報 DB統計情報 テーブルサイズ 統計が作成される列情報 [ID] [int] IDENTITY(1,1) NOT NULL ID列 select * from sys.stats where name like '%_WA_Sys_0000000A_6B7099F3%'; 自動作成 別の統計に関する情報を取得する select * From sys.dm_db_stats_properties (1802541555, 3) 私の空の統計と比較して： 「生成スクリプト」からの統計+ヒストグラム： /****** Object: Statistic [_WA_Sys_0000000A_6B7099F3] Script Date: 2/1/2019 10:18:19 AM ******/ …
4
整数入力から日付を再構築する最良の方法は何ですか？
私はたくさんの財務レポートを持っています。それらを変数として2つの入力（年と四半期）に渡せるようにしたいと考えています。 私はこのようにしていますが、本当に好きではありません。 declare @quarter int, @year int, @date date set @quarter = 4 set @year = 2018 set @date = cast(@year as varchar(4)) + '-01-01' set @date = dateadd(quarter, @quarter - 1, @date) print @date 質問整数入力から日付を再構築する最良の方法は何ですか？ 望ましい結果： 2018-10-01
4
SQL Server 2016の移植性を最大化するためのベストプラクティス
ソリューションのプロトタイプを開発する場合、多くの場合、テクノロジーはまだ決定されておらず、完成品で使用されるものと同じではない可能性があります。 このシナリオでは、別のサーバーへの最終的な移行を簡略化するために、Microsoft SQL Serverを使用してクエリをできるだけ標準的に作成する傾向があります。 SQL Serverで直接、またはSQL Server Management Studio（SSMS）を介して、T-SQLダイアレクトを介した標準SQLの使用を強制する方法またはいくつかの既知の方法はありますか？
2
古い値でのテンポラルテーブルのパフォーマンスが低い
テンポラルテーブル内の履歴レコードにアクセスすると、奇妙な問題が発生します。AS OF副次句を介してテンポラルテーブルの古いエントリにアクセスするクエリは、最近の履歴エントリのクエリよりも時間がかかります。 履歴テーブルはSQL Serverによって生成され（日付列にクラスター化インデックスが含まれ、ページ圧縮を使用）、履歴テーブルに5,000万行を追加しました。クエリは約25,000行を取得しました。 問題の根本的な原因を特定しようとしましたが、特定できませんでした。これまでにテストしました： クラスター化インデックスを含む5,000万行のテストテーブルを作成して、速度の低下が単にボリュームによるものかどうかを確認します。一定の時間（約400ミリ秒）で25K行を取得できました。 履歴テーブルからページ圧縮を削除します。これは検索時間には影響しませんでしたが、テーブルのサイズを大幅に増やしました。 ID列と日付列を使用して、履歴テーブルの行に直接アクセスしてみました。ここが少し面白かった場所です。AS OFサブ句の場合と同様に、約1200ミリ秒かかるテーブルの約400ミリ秒で、古い行にアクセスできました。テストテーブルで日付列のフィルタリングを試みたところ、ID列でのフィルタリングと比較して、同様の速度低下に気づきました。これは、日付の比較がいくつかの減速の背後にあると私に信じさせます。 私はこれをもっと見たいのですが、間違った木を吠えないようにしたいのです。まず、テンポラルテーブルの古い履歴データにアクセスするときに、他の誰かがこれと同じ動作を経験しましたか？次に、パフォーマンスの問題の根本原因をさらに特定するために使用できるいくつかの戦略は何ですか（実行プランを調べ始めたばかりですが、それでも私には少し謎めいています）。 実行計画 これらは単純な取得クエリです。最初のクエリは古い行にアクセスし、2番目のクエリは新しい行にアクセスします。 古い行：実行時間〜1200ms 最近の行〜350msの実行時間 テーブルの詳細 これらはテンポラルテーブルの列です。履歴テーブルには同じ列がありますが、（履歴テーブルの要件に従って）主キーはありません。 以下は、履歴テーブルのインデックスです。
2
ピボットの列として定期的な平日を作成するにはどうすればよいですか？
私はプログラミングとデータベースの初心者であり、次のシナリオでいくつかの助けに感謝します。 SQL ServerでPHPを使用しています。私は従業員の出席システムを構築しています。月を行、すべての曜日名を列（特定の年）として（ピボット）テーブルを作成したいと考えています。セルの値は日数です（1、2、3 ... 31）。 セルの背景色（テーブル列として既に存在）は、従業員の休暇のタイプを宣言します。テーブルには次の列がありますemployee_id, leave_date, leave_type, leave_type_color。 以下のような結果を達成したい： ありがとうございました。
8 sql-server  php  pivot 
2
予測レビューのためのデータベース設計
私はリレーショナルデータベースについてもっと学びたいと思っており、実際に何かをするために学ぶより良い方法はないと思いました。私は個人的な予算の会計と予測を見る個人的な試みをすることにしました。これまでにいくつかの調査を行ったので、現在のデータベースの設計と正規化について洞察を得たいと思います。 現在のデータベース設計に関するあなたの考えと提案は何ですか？私はあなたが私を助けるのをよりよく助けるためにいくつかの情報を以下に含めました:) 開示：これは個人的なプロジェクトです。宿題や仕事のためではありません。 ビジネスの事実 銀行ACCOUNTは多くのことができますENTRIES はENTRY、CREDITまたはDEBIT アンはENTRY、それは上の貸方かに引き落とされた日付を持っています アンはENTRYシングルを持っていますPAYEE ENTRYAに関連付けることができますBUDGET CATEGORY A CREDITはENTRY のCREDIT説明がありますENTRY A CREDITは将来的にスケジュールできます A CREDITは頻度や量で再発する可能性があります A DEBITはENTRY のDEBIT説明がありますENTRY A DEBITは将来的にスケジュールできます A DEBITは頻度や量で再発する可能性があります A PAYEEには名前があります AにBUDGETは多くのBUDGET CATEGORIES A BUDGETは単一のカレンダーにのみ関連付けることができます A BUDGET CATEGORYは多くのENTRIES A BUDGET CATEGORYには名前があります A BUDGET CATEGORYにはBUDGET金額があります A FORECASTには開始日があります A FORECASTには終了日があります A FORECASTには期首残高があります AにFORECASTは多くのFORECASTED DAYS A FORECASTは1つFORECASTED BUDGET …
1
非常に巨大な（100,000,000+）テーブルのTOP（1）BY GROUP
セットアップ 〜115,382,254行の巨大なテーブルがあります。テーブルは比較的単純で、アプリケーションプロセスの操作を記録します。 CREATE TABLE [data].[OperationData]( [SourceDeciveID] [bigint] NOT NULL, [FileSource] [nvarchar](256) NOT NULL, [Size] [bigint] NULL, [Begin] [datetime2](7) NULL, [End] [datetime2](7) NOT NULL, [Date] AS (isnull(CONVERT([date],[End]),CONVERT([date],'19000101',(112)))) PERSISTED NOT NULL, [DataSetCount] [bigint] NULL, [Result] [int] NULL, [Error] [nvarchar](max) NULL, [Status] [int] NULL, CONSTRAINT [PK_OperationData] PRIMARY KEY CLUSTERED ( [SourceDeviceID] ASC, [FileSource] …
1
単一のテーブルで複数の一意の制約を使用すると、設計が悪いと見なされますか？
私はPostgreSQLのINSERT INTO .. ON CONFLICT (..) DO UPDATE ..構文を見ていましたが、それを使用して複数の一意制約チェックを実行することはできません。つまり、複合一意インデックスを列名で参照するかON CONFLICT (Name, Symbol)（一意のインデックスがこれらの2つの列に対して定義されている場合）、または主キーを使用します。列に2つの個別の一意のインデックスを定義する場合、チェックできるのは1つだけです。 CREATE TABLE student (Id int primary key, Name varchar(50), Symbol varchar(50), CONSTRAINT col1_unique UNIQUE (Name), CONSTRAINT col2_unique UNIQUE (Symbol) ); INSERT INTO student (Id, Name, Symbol) VALUES (1, 'John', 'J'), (2, 'David', 'D'), (3, 'Will', 'W'); INSERT INTO …
1
クエリストアによるブロッキング。クリアまたは無効にできません
2016 SQL Serverを最近SP2に更新し、最新のCU（KB4458621）を2018年8月にリリースしました。ちょうど最終日かそこらで、いくつかのブロックが発生していることに気付きました。SPID b / cはユーザープロセスではないため、強制終了できません。SP_WHO2によると、コマンドは「Query Store ASYN」です。スクリプトとUIを使用して、データをパージし、クエリストアを無効にしてみました。何も機能していないようで、スピンしてからブロックが発生し始めます。他に誰かがこの問題を抱えていますか？誰でも私がクエリストアを無効にする方法を理解するのを手伝ってくれる？SP_WhoIsActive @show_System_SPIDS = 1以下の結果（クエリストアの結果のみ） 更新-これにより、TempDBドライブがいっぱいになります。数時間後に再起動してみて、問題が解決するかどうか確認してください。投稿し続けます。 ありがとう、ネイト
1
SQL Server関数をオーバーロードすることは可能ですか？
SQLサーバー関数をオーバーロードすることは可能ですか？ltrimのようなスカラー、またはcountのような集約関数のどちらですか？ これが本当に、本当に、悪い考えだったとしても。出来ますか？ T-SQLのユーザー定義関数のオーバーロードの複製のいくらか？それは2005年のバージョンだったので、それは100％複製ではないと言えるでしょう。多分これは変わったのですか？
1
次のチェックポイントの前にシステムに障害が発生した場合、ダーティページはどうなりますか？
完全復旧モデルを使用しているデータベースを想定して、SQL Serverでレコードが（INSERT/ UPDATEなどによって）書き込まれると、先読みロギングにより、データページを変更する前に変更がログファイルに書き込まれることが保証されます。 ログとデータページの両方のエントリがRAMに作成され、後でチェックポイントによってディスクにコミットされます。 システムクラッシュ（議論のために電力損失）が発生した場合、RAMの内容がシステムの再起動後も存続しないため、ダーティページ（RAMで変更されてもディスクにコミットされないIEデータ）はどうなりますか？ ？ 編集 いくつかのテストの後、ダーティページが失われていないことがわかりますが、理由はわかりません。 このチュートリアルを使用して テストデータベースを作成する CREATE DATABASE DirtyPagesDB GO USE DirtyPagesDB GO 自動チェックポイントをオフにする DBCC TRACEON(3505, -1); DBCC TRACESTATUS(); テーブルを作成し、データを挿入して、チェックポイントを発行します。 CREATE TABLE t1 (Speaker_Bio CHAR(8000)) GO INSERT INTO t1 VALUES ('SQL'),('Authority') GO CHECKPOINT ダーティページがないことを確認する -- Get the rows of dirtied pages SELECT database_name = d.name, OBJECT_NAME …
2
ハッシュインデックスが等価検索でBtreeよりも速くならないのはなぜですか？
ハッシュインデックスをサポートするPostgresのすべてのバージョンについて、少なくともバージョン8.3までは、ハッシュインデックスがbtreeインデックスより「類似または遅い」または「良くない」という警告または注意があります。ドキュメントから： バージョン7.2： 注：ハッシュインデックスのユーティリティは限られているため、通常はハッシュインデックスよりもBツリーインデックスの方が適しています。=比較の場合でも、ハッシュインデックスが実際に Bツリーよりも速いという十分な証拠はありません。さらに、ハッシュインデックスにはより粗いロックが必要です。セクション9.7を参照してください。 バージョン7.3（および8.2まで）： 注：テストの結果、PostgreSQLのハッシュインデックスはBツリーインデックスと同じかそれより遅いことがわかりました。また、ハッシュインデックスのインデックスサイズとビルド時間ははるかに悪いです。また、同時実行性が高いと、ハッシュインデックスのパフォーマンスが低下します。これらの理由により、ハッシュインデックスの使用はお勧めしません。 バージョン8.3： 注：テストは実行しないように、PostgreSQLのハッシュインデックスを示したは良い B-treeインデックスよりも、およびハッシュインデックスのインデックスサイズと構築時間ははるかに悪いです。さらに、ハッシュインデックス操作は現在WALログに記録されていないため、データベースクラッシュ後にハッシュインデックスをREINDEXで再構築する必要がある場合があります。これらの理由により、ハッシュインデックスの使用は現在推奨されていません。 このバージョン8.0のスレッドでは、ハッシュインデックスが実際にbtreeよりも高速であるケースを発見したことはなかったと主張しています。 バージョン9.2でさえ、このブログの投稿（2016年3月14日）によると、実際のインデックスを作成する以外のパフォーマンス向上はほとんどありませんでした： AndréBarbosaによるPostgresのハッシュインデックス。 私の質問は、それはどのようにして可能ですか？ 定義により、ハッシュインデックスはO(1)操作であり、btreeはO(log n)操作です。ではO(1)、正しいブランチを見つけてから正しいレコードを見つけるよりも、ルックアップの速度が遅い（またはそれに似ている）のはどうしてでしょうか。 索引付け理論について、それを可能にすることは決してありません。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.