データベース管理者

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

4
結果のテーブル定義が不明なピボットCROSS JOINを生成するにはどうすればよいですか？
名前と値を持つ未定義の行数を持つ2つのテーブルがある場合、CROSS JOINそれらの値に対して関数のピボットをどのように表示しますか。 CREATE TEMP TABLE foo AS SELECT x::text AS name, x::int FROM generate_series(1,10) AS t(x); CREATE TEMP TABLE bar AS SELECT x::text AS name, x::int FROM generate_series(1,5) AS t(x); たとえば、その関数が乗算である場合、以下のような（乗算）テーブルをどのように生成しますか？ これらの(arg1,arg2,result)行はすべて、次を使用して生成できます。 SELECT foo.name AS arg1, bar.name AS arg2, foo.x*bar.x AS result FROM foo CROSS JOIN bar; したがって、これは表示の問題にすぎません。これは、カスタム名（CASTテキストへの単なる引数ではなくテーブルに設定された名前） CREATE TEMP …
7
複合インデックス：最も選択的な列が最初ですか？
私は読んでいてcomposite indexes、注文について少し混乱しています。このドキュメント（半分以下）が言います 一般に、最も頻繁に使用されると予想される列をインデックスの最初に配置する必要があります。 しかし、それが言った直後 最も選択的な列を最初に置く複合インデックスを作成します。つまり、値が最も多い列です。 オラクルはまた、ここで言い換えると すべてのキーがWHERE句で同じ頻度で使用される場合、CREATE INDEXステートメントでこれらのキーを最も選択性の高いものから最も選択性の低いものに並べると、クエリのパフォーマンスが向上します。 しかし、私は違う答えをするSOの答えを見つけました。それは言う 列を最も選択性の低い列を最初に、最も選択性の高い列を最後に配置します。単独で使用される可能性が高いカラムとのタイリードの場合。 私が参照した最初のドキュメントは、最も頻繁に使用されるものを最初に確認する必要があると述べていますが、SOの答えは、タイブレークのみであるべきだと述べています。次に、順序も異なります。 このドキュメントはまた語るskip scanningと言います スキップスキャンは、複合インデックスの先頭列に個別の値がほとんどなく、インデックスの先頭以外のキーに個別の値が多数ある場合に有利です。 別の記事は言う プレフィックス列は、クエリで最も識別性が高く、最も広く使用される必要があります 最も差別的であることは最も特徴的だと思います。 この研究はすべて、私に同じ質問を導きます。最も選択的な列は最初か最後か？最初の列は、タイブレークで最も使用され、最も選択的である必要がありますか？ これらの記事は互いに矛盾しているように見えますが、いくつかの例を提供しています。私が集めたものから、もしあなたが予想しているなら、注文least selective columnの最初のものであることがより効率的であるように思われますIndex Skip Scans。しかし、それが正しいかどうかはよくわかりません。
1
可用性グループのセカンダリデータベースで大きなクエリを実行すると、プライマリデータベースのトランザクションパフォーマンスに影響しますか？
SSRSおよびTableauのレポート用に、リアルタイムまたはほぼリアルタイムのデータを提供する必要があります。実稼働OLTPシステムが長時間実行されるクエリによって悪影響を受けるのは望ましくありません。可用性グループのセカンダリデータベースで大きなクエリを実行すると、プライマリデータベースのトランザクションパフォーマンスに影響しますか？
2
SQLの総参加制約との多対多の関係の実装
次のエンティティ関係図に示されているシナリオをSQLに実装するにはどうすればよいですか？ それが示されているように、すべてのAエンティティタイプの発生に関連しなければならない少なくとも1つの B（二重接続線で示す）の対応、およびその逆。次の3つのテーブルを作成する必要があることを知っています。 CREATE TABLE A ( a INT NOT NULL, CONSTRAINT A_PK PRIMARY KEY (a) ); CREATE TABLE B ( b INT NOT NULL, CONSTRAINT B_PK PRIMARY KEY (b) ); CREATE TABLE R ( a INT NOT NULL, b INT NOT NULL, CONSTRAINT R_PK PRIMARY KEY (a, b), CONSTRAINT …
3
「使用」後にMySQLデータベースがフリーズする
私は最近、かなり愚かな間違いを犯し、Ubuntuのインストールを破損しました。それを解決するために、ライブCDで起動し、データベースファイルをコピーしました。しかし、今では古いインストールから新しいインストールにフォルダーをコピーしました。「use database_name」と入力するたびに、これでフリーズします： mysql> use my_database_name; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A そして、ターミナルを与えずにフリーズします。
17 mysql  backup 
3
HAProxyおよびPGBouncerを使用したPostgreSQLの高可用性/スケーラビリティ
Webアプリケーション用に複数のPostgreSQLサーバーがあります。通常、1つのマスターとホットスタンバイモードの複数のスレーブ（非同期ストリーミングレプリケーション）。 接続プーリングにPGBouncerを使用します：ローカルホスト上のデータベースに接続する各PGサーバー（ポート6432）にインストールされた1つのインスタンス。トランザクションプールモードを使用します。 スレーブ上の読み取り専用接続の負荷を分散するために、HAProxy（v1.5）を次のような設定で使用します： listen pgsql_pool 0.0.0.0:10001 mode tcp option pgsql-check user ha balance roundrobin server master 10.0.0.1:6432 check backup server slave1 10.0.0.2:6432 check server slave2 10.0.0.3:6432 check server slave3 10.0.0.4:6432 check したがって、私のWebアプリケーションはhaproxy（ポート10001）に接続します。これは、各PGスレーブ上に構成された複数のpgbouncerで接続を負荷分散します。 ここに私の現在のアーキテクチャの表現グラフがあります： これは次のように非常にうまく機能しますが、いくつかの実装がまったく異なることを認識しています。Webアプリケーションは、複数のPGサーバーで負荷分散するHAproxyに接続する単一のPGBouncerインスタンスに接続します。 最善のアプローチは何ですか？最初のもの（私の現在のもの）または2番目のものですか？あるソリューションが他のソリューションより優れている点はありますか？ ありがとう
2
tinyint（N）の意味は何ですか？
数値データ型で引数の長さを使用する場合、私が知る限り、これは表示幅を指定します。 私は次を試しました： mysql> create table boolean_test (var1 boolean, var2 tinyint); Query OK, 0 rows affected (0.10 sec) mysql> show create table boolean_test; +--------------+------------------------- | Table | Create Table +--------------+------------------------- | boolean_test | CREATE TABLE `boolean_test` ( `var1` tinyint(1) DEFAULT NULL, `var2` tinyint(4) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | +--------------+--------------------------- …
2
SQL Server：TCPまたは名前付きパイプを使用するか、デフォルトを使用する必要がありますか？
同じLAN内の別のサーバー上の.NET 4クライアントアプリケーションからSQL Server 2008 R2に接続する場合、3つの異なるネットワークプロトコルを設定できます。 TCP 名前付きパイプ 接続文字列には何も設定せず、デフォルトを使用します ベストプラクティスとは何ですか？何を選ぶ？ 追加情報：TCPと名前付きパイプの両方が、サーバーとクライアントの両方で有効になっています。アプリケーションはデータベースミラーリングを使用しています。クライアントとサーバーは高速LANで通信します。 まれで偽の接続とタイムアウトの問題があるため、これを調査しています。（ただし、それにもかかわらず、ベストプラクティスを知りたい）。 MSDNにはこのテーマに関する記事がありますが、非常に一般的で曖昧です。有用なアドバイスや推奨事項はありません。
6
DB階層を表示しようとすると「ロック要求のタイムアウト期間を超えました」エラー
データベースに問題があります。 通常よりはるかに遅くなりますが、基本的なクエリを実行できます。 SSMS Object Explorerでテーブル、ビュー、またはプロシージャの階層ツリーを表示しようとすると、が表示されますlock request time out period exceeded。 このデータベース内のオブジェクトで実行される私のSSRSレポートは完了していません。 このデータベースに保存されているプロシージャに関連付けられているジョブも実行されません。 私が使ってみましたsp_who2が、これは問題を解決していない、データベース上のすべての接続を見つけ、殺すために。 ここで何が起こっていますか？どうすれば解決できますか？
7
テーブルの列名を表示する方法は？
ケースは簡単です。SQLクエリインターフェイスのみを持つMySQLデータベースがあり、クエリのデータベース構造を知りたい場合。show tables;コマンドを使用してテーブルを一覧表示できますが、個々の列名をどのように表示しますか？ （SELECTステートメントはEmpty setデータが存在せず、したがって使用できない場合に表示します。）
17 mysql 
3
トリガーが有効な場合のレコードの削除が遅い
これは以下のリンクで解決されたと思います-回避策は動作します-しかし、パッチは動作しません。Microsoftサポートと協力して解決します。 http://support.microsoft.com/kb/2606883 わかりましたので、誰かがアイデアを持っているかどうかを確認するためにStackOverflowに捨てたい問題があります。 これはSQL Server 2008 R2でのことに注意してください 問題：15000レコードのテーブルから3000レコードを削除すると、トリガーが有効な場合は3〜4分かかり、トリガーが無効な場合は3〜5秒しかかかりません。 テーブルのセットアップ メインとセカンダリと呼ばれる2つのテーブル。セカンダリには削除するアイテムのレコードが含まれているため、削除を実行するとセカンダリテーブルに参加します。deleteステートメントの前にプロセスが実行され、削除するレコードがセカンダリテーブルに入力されます。 ステートメントを削除： DELETE FROM MAIN WHERE ID IN ( SELECT Secondary.ValueInt1 FROM Secondary WHERE SECONDARY.GUID = '9FFD2C8DD3864EA7B78DA22B2ED572D7' ); このテーブルには多くの列と約14の異なるNCインデックスがあります。トリガーが問題であると判断する前に、さまざまなことを試しました。 ページロックをオンにします（デフォルトではオフになっています） 手動で収集された統計 統計の自動収集を無効にしました 検証済みのインデックスの健全性と断片化 テーブルからクラスター化インデックスを削除しました 実行計画を調査しました（インデックスの欠落として表示されるものはなく、実際の削除にかかるコストは70％で、レコードの結合/マージには約28％でした） トリガー テーブルには3つのトリガーがあります（挿入、更新、削除の各操作に1つ）。削除トリガーのコードを変更して、単に戻るようにした後、1つを選択して、トリガーされる回数を確認しました。操作全体で1回だけ起動します（予想どおり）。 ALTER TRIGGER [dbo].[TR_MAIN_RD] ON [dbo].[MAIN] AFTER DELETE AS SELECT 1 RETURN 要点をまとめると トリガーがオンの場合-ステートメントの完了には3〜4分かかります トリガーがオフの場合-ステートメントの完了には3〜5秒かかります …
3
より効率的なのは、where句または100万行以上のテーブルとの結合ですか？
1つのテーブルに250MMの行があり、ほとんどのクエリで結合する別のテーブルに15MM未満の行があるWebサイトを実行します。 サンプル構造： MasterTable (Id, UserId, Created, Updated...) -- 15MM Rows DetailsTable (Id, MasterId, SomeColumn...) -- 250MM Rows UserTable (Id, Role, Created, UserName...) -- 12K Rows これらすべてのテーブルに対していくつかのクエリを定期的に行う必要があります。1つは、無料ユーザー（最大1万人の無料ユーザー）の統計を取得することです。 Select Count(1) from DetailsTable dt join MasterTable mt on mt.Id = dt.MasterId join UserTable ut on ut.Id = mt.UserId where ut.Role is null and …
4
TVFにラップすると、このクエリが大幅に遅くなるのはなぜですか？
数秒で実行されるかなり複雑なクエリがありますが、テーブル値の関数にラップすると、はるかに遅くなります。実際には終了させて​​いませんが、終了せずに最大10分間実行されます。唯一の変更点は、2つの日付変数（日付リテラルで初期化された）を日付パラメーターに置き換えることです。 7秒で実行 DECLARE @StartDate DATE = '2011-05-21' DECLARE @EndDate DATE = '2011-05-23' DECLARE @Data TABLE (...) INSERT INTO @Data(...) SELECT... SELECT * FROM @Data 少なくとも10分間実行 CREATE FUNCTION X (@StartDate DATE, @EndDate DATE) RETURNS TABLE AS RETURN SELECT ... SELECT * FROM X ('2011-05-21', '2011-05-23') 以前にRETURNS @Data TABLE（...）句を使用して関数をマルチステートメントTVFとして記述しましたが、インライン構造のそれを交換しても目立った変更はありませんでした。TVFの長い実行時間は実際のSELECT * FROM X時間です。実際にUDFを作成するには数秒かかります。 …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.