データベース管理者

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

1
LOG_BACKUP log_reuse_wait_descを使用したSQL Server 2012シンプルリカバリモデル
私は私自身の調査をやっている間に、データベース、なぜ、誰もが知っているんSIMPLE復旧モデルを持っているLOG_BACKUPためにlog_reuse_wait_desc? SQL Server 2012 SP1。数週間前に作成されたデータベース。レプリケーションもミラーリングもログ配布もありません。 私たちは、データベースのバックアップを行なったし、それは示して、別のインスタンスに復元SIMPLEし、NOTHING中にlog_reuse_wait他のインスタンスに。しかし、別のインスタンスへの復元は、復元操作がトランザクションをロールフォワード/ロールバックするときに問題を再現する良い方法だとは思いません。

2
最長の接頭辞を見つけるアルゴリズム
テーブルが2つあります。 最初のものは接頭辞を持つテーブルです code name price 343 ek1 10 3435 nt 4 3432 ek2 2 2つ目は、電話番号を含む通話記録です number time 834353212 10 834321242 20 834312345 30 各レコードのプレフィックスから最長のプレフィックスを見つけるスクリプトを作成し、このすべてのデータを次のように3番目のテーブルに書き込む必要があります。 number code .... 834353212 3435 834321242 3432 834312345 343 番号834353212の場合、「8」をトリミングしてから、プレフィックステーブルから最長のコードである3435 を見つける必要があります。常に最初に「8」を削除し、プレフィックスを先頭に置く必要があります。 私は非常に悪い方法でずっと前にこの課題を解決しました。これは、各レコードに対して多くのクエリを実行する恐ろしいperlスクリプトでした。このスクリプト: 呼び出しテーブルから数値を取得し、ループ内でlength(number)から1 => $ prefixまでの部分文字列を実行します クエリを実行します: '$ prefix'のようなコードのプレフィックスからcount(*)を選択します count> 0の場合、最初のプレフィックスを取得してテーブルに書き込みます 最初の問題はクエリ数です- call_records * length(number)です。第二の問題はLIKE表現です。遅いと思います。 私は2番目の問題を解決しようとしました: …

2
1つのデータベースをフェイルオーバーした場合、同じミラーエンドポイントを共有する他のデータベースもフェイルオーバーしますか?
単一のSQL Serverインスタンスでミラーリングするための2つのデータベースセットアップがあります。テストデータベースと本番データベースです。どちらも、まったく同じエンドポイントを使用して別のサーバーにミラーリングされます。 テストデータベースのデータベースプロパティに移動して[フェールオーバー]ボタンをクリックすると、両方のデータベースがミラーエンドポイントを共有し、それらのサーバーネットワークアドレスプロパティが同じであるため、本番データベースもフェールオーバーしますか? 2番目のデータベースのミラーリングをセットアップするときに、何も新しく構成する必要がなかったので心配です。既存の情報をすべて使用しただけです。 データベースプロパティの[フェールオーバー]ボタンを使用すると、そのエンドポイントを使用するすべてのデータベース、またはプロパティを表示している特定のデータベースのみがフェールオーバーされますか?

1
Postgres:count(*)とcount(id)
私が見た中でのドキュメントの違いをcount(*)してcount(pk)。の存在を知らないままcount(pk)(pkはSERIAL PRIMARY KEY)を使用していたcount(*)。 私の質問はPostgresの内部最適化についてです。SERIAL PRIMARY KEYすべての行にa が存在し、偽になることはなく、行をカウントするだけであることをピックアップするのに十分スマートですか?それとも各行に対して冗長な述語チェックを行いますか?これはおそらく無意味な最適化では多すぎると私は同意しますが、私は興味があるだけです。 私はの出力で見ていたEXPLAINとEXPLAIN VERBOSEのためにcount(*)、count(id)そしてcount(id > 50)かどうかを確認するためにEXPLAIN、その出力に述語をチェック述べました。そうではありません。

3
小数点の自動丸めの問題
質問は比較的簡単です。中間結果が巨大な10進数である3つの列を計算する必要があります。SQLServerで、キャスト/変換に関係なく基本的に小数点を丸める問題が発生しています。 たとえば、単純な除算を1234/1233としてみましょう。電卓は1,00081103000811を生成します。しかし、SQL Serverでこれを行うと、次のようになります。 -- Result: rounded at 1.000811000... with trailing zeroes up until the 37 precision SELECT CAST(CAST(1234 AS DEC(38,34))/CAST(1233 AS DEC(38,34)) AS DEC(38,37)) -- Result: rounded at 1.000811 SELECT CONVERT(DECIMAL(38,32), 1234)/CONVERT(DECIMAL(38,32),1233) -- Correct result at 1,00081103000811 -- But this requires the zeroes to be put in manually when you …

5
SQL Serverの最大メモリ設定
SQL Server 2008とWebベースのアプリケーションを、2 GBのメモリしか利用できない単一の専用サーバーで実行しています。 他で言及されているように、SQL Serverは定期的に最大98%の物理メモリを使用します。これは、サーバーで実行されているWebアプリケーションの速度を低下させるようです。 SSMSの[サーバーのプロパティ]の[メモリ]で、[最大サーバーメモリ(MB)]が2147483647に設定されている 私の質問は、利用可能なメモリの量を考えると、最大サーバーメモリボックスに入れる推奨数は何ですか?また、同じサーバーがWebアプリケーションも実行しているということですか? さらに、SQL Serverの実行中にこの数を変更しても安全ですか? アドバイスありがとうございます。

3
tempdbログファイルのベストプラクティス
tempdbデータファイルの構成方法に関するブログを何度も読みましたが、tempdbログファイルに関する情報は見つかりませんでした。 tempdbで現在使用している戦略は次のとおりです。 tempdbデータファイルを分割する方法について、Paul Randalの推奨事項を使用しました tempdbデータファイルのサイズを最大に設定し、自動拡張を無効にしました。たとえば、100 GBの空きディスク領域があり、8つのtempdbデータファイルのサイズをそれぞれ10 GBに設定します。これにより、Brent Ozarが推奨するディスクの断片化が防止され、ログファイル用に20 GBが解放されます。 しかし、私が言ったように、誰もtempdbログファイルについて話していません。どうすればいいですか?私のセットアップでは、このファイルはtempdbデータファイルと同じ場所にあります。tempdbログファイルで使用するサイズと自動拡張値は何ですか?

2
SQL Serverのデータ圧縮は、読み取り専用のデータベースに非常に適していますか?
私が読んだSQL Serverのデータ圧縮に関するいくつかの文献では、書き込みコストが通常必要なものの約4倍に増加すると述べています。また、これがデータ圧縮の主な欠点であることを暗示しているようです。読み取り専用アーカイブデータベースの場合、100%埋められたページのデータ圧縮を使用すると、パフォーマンスが(ほとんど例外なく)向上することを強く意味します。 上記の説明は正しいですか? データ圧縮とそれ以外の場合の主な「違い」は何ですか(読み取り用) 「CPU + x%」? 「IO -y%」? ページ分割発生? tempdbの使用法? RAM使用量? そして書くために? この質問のために、コンテキストを大きな(> 1TB)データベースのページレベルの圧縮に制限できますが、追加のコメントはいつでも歓迎します。 参照: SQL Serverストレージエンジンブログ(DWシナリオは圧縮が非常に有利であることを示しています) データ圧縮:戦略、容量計画、およびベストプラクティス 圧縮対象を決定するためのより詳細なアプローチには、各テーブルとインデックスのワークロード特性の分析が含まれます。次の2つの指標に基づいています。 U:特定のテーブル、インデックス、またはパーティションに対する更新操作の、そのオブジェクトに対する合計操作に対する割合。Uの値が低い(つまり、テーブル、インデックス、またはパーティションが頻繁に更新されない)ほど、ページ圧縮の候補として適しています。 S:そのオブジェクトに対する操作の合計に対する、テーブル、インデックス、またはパーティションに対するスキャン操作の割合。Sの値が大きいほど(つまり、テーブル、インデックス、またはパーティションがほとんどスキャンされる)、ページ圧縮の候補として適しています。 上記の両方は、DWスタイルのデータベース(読み取り集中型/排他型のビッグデータ操作)のページ圧縮を推奨する方向に明らかに偏っています。

1
エラー:セットを受け入れることができないコンテキストで呼び出されたset_valued関数。どんな内容ですか?
私はubuntu 12.04でPostgresql 9.1を使用しています。 私の質問へのクレイグの回答に触発されたsetofタイプまたはsetofレコードの連結私はreturn query、setof recordこのplpgsql関数に、、およびシリーズジェネレーターを使用するとうまくいくと思いました: create or replace function compute_all_pair_by_craig(id_obj bigint) returns setof record as $$ begin return query select o.id, generate_series(0,o.value) from m_obj as o; end; $$ language plpgsql; 実行中にエラーが発生します: ERROR: set_valued function called in context that cannot accept a set なにが問題ですか ?Craigとは逆に、関数に返すように指示しますsetof record。 私はCraigとまったく同じように機能する何かを実現できます。つまり、型create type pair_id_value as …


2
SQL Server 2008 R2トランザクションログを使用したCOPY_ONLY完全バックアップの復元
調査を行った後、この質問に対する答えを見つけることができないようです。 背景次の3つの要件に適合するバックアップ計画をセットアップしようとしています。 バックアップの信頼性、夜間の完全バックアップ から復元できるトランザクションログのバックアップ 使用されるディスク容量が少ない 監査ツールでは、バックアップにローカルでアクセスできる必要があります したがって、これらのニーズに合わせるために、フルバックアップを毎週、差分を毎日、トランザクションを毎時と考えています。その後、毎晩、オフサイトに出荷できるcopy_onlyバックアップが実行されます。このバックアップは、ログチェーンが壊れないように行われ、ローカルのディスクスペースを大量に消費することなく、信頼性の高い夜間フルバックアップをオフサイトで実行できます。 質問copy_onlyバックアップから復元し、後でトランザクションログを復元することは可能ですか。 例を挙げて、私が何を話しているのかを理解してください。 以下のリストを使用して、FullbackupCOPY_ONLYC.bakに続いてTransactionbackupG.trn、TransactionbackupH.trn、最後にTransactionbackupI.trnを復元できるかどうか疑問に思っています。 > ---List of Backups--- FullbackupA.bak 01/01/2013 00:00:00 > DifferntialbackupA.bak 02/01/2013 00:00:00 FullbackupCOPY_ONLYA.bak 02/01/2013 00:00:00 > TransactionbackupA.trn 02/01/2013 01:00:00 > TransactionbackupB.trn 02/01/2013 02:00:00 > TransactionbackupC.trn 02/01/2013 03:00:00 > DifferntialbackupB.bak 03/01/2013 00:00:00 FullbackupCOPY_ONLYB.bak 03/01/2013 00:00:00 > TransactionbackupD.trn 03/01/2013 01:00:00 > TransactionbackupE.trn 03/01/2013 …

3
インデックススキャンではなくPostgreSQL順次スキャンなぜですか?
こんにちは、私はPostgreSQLデータベースクエリに問題があり、誰かが手伝ってくれるかどうか疑問に思っています。いくつかのシナリオでは、私のクエリは、2つのテーブルdataとを結合するために使用した、私が作成したインデックスを無視しているようdata_areaです。これが発生すると、シーケンシャルスキャンが使用され、クエリが非常に遅くなります。 順次スキャン(〜5分) Unique (cost=15368261.82..15369053.96 rows=200 width=1942) (actual time=301266.832..301346.936 rows=153812 loops=1) CTE data -> Bitmap Heap Scan on data (cost=6086.77..610089.54 rows=321976 width=297) (actual time=26.286..197.625 rows=335130 loops=1) Recheck Cond: (datasetid = 1) Filter: ((readingdatetime >= '1920-01-01 00:00:00'::timestamp without time zone) AND (readingdatetime <= '2013-03-11 00:00:00'::timestamp without time zone) AND (depth >= 0::double …

3
RESTful APIのSQLデータベース構造
RESTful APIを作成しています。リソースを中心にデータベーステーブルを設計する最良の方法を決定するのに苦労しています。 最初は、リソースごとのテーブルが適していますが、これにより、リソースチェーンをさらに下っていくと、テーブルが指数的に大きくなるのではないかと心配しています。 たとえば、ユーザー、クライアント、販売の3つのリソースがあるとします。ユーザーは私のAPIのサブスクライバーであり、クライアントはユーザーの顧客であり、販売は各クライアントがユーザーアカウントに対して行った購入です。 次のように販売リソースにアクセスします GET /users/{userID}/clients/{clientID}/sales/{salesID} したがって、10人のユーザーがあり、それぞれに10人の顧客がいて、それぞれの顧客について10件の売上がある場合、テーブルサイズは、リソースチェーンを下に行くほど大きくなります。 SQLが大きなテーブルに対応できるとは確信していますが、読み取りと書き込みがどのように遅くなるかはわかりません。上の例はそれを説明していないかもしれませんが、私のAPIは次第に多くの書き込みと読み取りを行って、リソースチェーンのさらに下に行きます。したがって、データベース内の最大のテーブルが、小さいテーブルよりも多くの回数読み書きされるシナリオがあります。 クエリを実行する前にテーブルを結合する必要もあります。その理由は、各ユーザーが同じ名前のクライアントを持つことを許可するためです。間違ったクライアントデータを取得しないように、usersテーブルとclientsテーブルは{userID}によって結合されます。これは販売にも当てはまります。大きなテーブルを結合して読み取りと書き込みを実行すると、処理がさらに遅くなりますか?

1
SQLサーバーは、count(*)の結果をint変数と比較する前にintに変換する必要があるのはなぜですか?
私のアプリケーションには多くのクエリがあり、having句でcount集計関数とint変数を比較しています。クエリプランでは、比較の前にimplicit_convertを確認できます。SQLサーバーのドキュメントに従って、カウント関数の戻り値の型がintであるため、これが発生する理由を知りたいです。では、なぜ2つのint値を比較するための暗黙の変換が必要なのでしょうか。 以下は、@ IdCountがint変数として定義されているそのようなクエリプランの一部です。 | --Filter(WHERE:([Expr1022] = [@ IdCount])) |-スカラー計算(DEFINE:([Expr1022] = CONVERT_IMPLICIT(int、[Expr1028]、0))) | --Stream Aggregate(GROUP BY:([MOCK_DB]。[dbo]。[Scope]。[ScopeID])DEFINE:([Expr1028] = Count(*)))


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