データベース管理者

環境： Postgres 9.1クラスターでストリーミングレプリケーション/ホットスタンバイを使用しているときに、スタンバイノードがダウンしたとしましょう。これは1日間停止したままで、その間にマスターで多くのDMLが発生します。スタンバイのrecovery.confには「restore_command」エントリは含まれませんが（WALジャーナルファイルからの復元用）、「primary_conninfo」文字列は含まれます（ストリーミングレプリケーション用）。 質問： マスターで1日変更した後、スタンバイを再び開始した場合。ストリーミングレプリケーションのみを使用して、「追いつく」（最終的にはマスターをミラーリングする状態になります）のでしょうか。または、WALファイルアーカイブを有効にし、停止中にアーカイブされたファイルを適用して通貨を確保する必要がありますか？ ここでWALアーカイブ/ストリーミングレプリケーションドキュメントを確認しましたが、WALアーカイブとストリーミングレプリケーションの両方を有効にする必要はないと述べていますが、WALファイルアーカイブを有効にせずにキャッチアップが発生するかどうかは不明です。 ありがとう！

16 postgresql  replication 

私は、大きなテーブルの任意の列に少なくとも1つの空白（NULL /空）値があるエントリのリストがあるかどうかをテストするためにできる簡単なクエリを見つけようとしています。 私のようなものが必要です SELECT * FROM table AS t WHERE ANY(t.* IS NULL) やりたくない SELECT * FROM table AS t WHERE t.c1 = NULL OR t.c2 = NULL OR t.c3 = NULL これは巨大なクエリになります。

16 sql-server  sql-server-2008  null 

環境 この質問は、SQLデータベースシステムとNoSQLデータベースシステムの両方でのインデックスの低レベルの実装の詳細に関するものです。質問はこれらの実装の単一ノード内に保存されたキーに特に関係するため、インデックスの実際の構造（B +ツリー、ハッシュ、SSTableなど）は無関係です。 バックグラウンド SQL（MySQLなど）およびNoSQL（CouchDB、MongoDBなど）データベースでは、データの列またはJSONドキュメントフィールドにインデックスを作成するときに、実際にデータベースに実行させるのは、本質的にすべてのソート済みリストを作成することですこれらの値と、その値に関連するレコードが存在するメインデータファイルへのファイルオフセット。 （簡単にするために、特定の実装のその他の難解な詳細を手で振り払うかもしれません） シンプルなクラシックSQLの例 インデックスを作成する単純な32ビットint主キーを持つ標準SQLテーブルを考えます。データファイルへの64ビットオフセットに関連付けられ、関連付けられた整数キーのディスク上のインデックスが作成されます。レコードは存続します。例： id | offset -------------- 1 | 1375 2 | 1413 3 | 1786 インデックス内のキーのディスク上の表現は、次のようになります。 [4-bytes][8-bytes] --> 12 bytes for each indexed value ファイルシステムとデータベースシステムでのディスクI / Oの最適化に関する標準的な経験則に固執して、ディスク上の4KBブロックにキーを保存するとします。 4096 bytes / 12 bytes per key = 341 keys per block インデックスの全体構造（B +ツリー、ハッシュ、ソート済みリストなど）を無視して、341キーのブロックを一度に読み書きし、必要に応じてディスクに戻します。 クエリの例 前のセクションの情報を使用して、「id = …

16 mongodb  index  nosql  couchdb 

このようなテーブル構造で日付範囲を取得する最も効率的な方法は何ですか？ create table SomeDateTable ( id int identity(1, 1) not null, StartDate datetime not null, EndDate datetime not null ) go との両方の範囲が必要だStartDateとしEndDateます。換言すれば、場合StartDateの間に落ちる@StartDateBeginと@StartDateEnd、とEndDateの間に落ちる@EndDateBeginと@EndDateEnd、その後、何かをします。 これについておそらくいくつかの方法があることは知っていますが、最も推奨されるのは何ですか？

16 sql-server  query-performance 

私はセットに直接オプション（複数可）を見つけることができませんUTF-8rellated Collations/Charsetsと同じで、他のSQLエンジンに設定することも可能ですが、SQL Serverの2005/2008はそこだけでラテン語とSQL照合順序は、SQL Serverの2005/2008に。 これらの照合/文字セットをSQL Serverエンジン（両方のバージョン）2005/2008 Win2008 OSで強制/インストールするオプションはありますか

16 sql-server  sql-server-2008  sql-server-2005  collation  encoding 

使用して複数の操作を実行する方法があるWITH文は？ 何かのようなもの WITH T AS ( SELECT * FROM Tbl ) BEGIN OPEN P_OUTCURSOR FOR SELECT * FROM T; SELECT COUNT(*) INTO P_OUTCOUNT FROM T; END; データとそのカウントを選択したい...

16 oracle  select  cte 

MySQL 5.0でこのInnoDBエラーが発生しました。Mysqldは完全に停止しましたが、その後ib_logfile0とib_logfile1を失いました。クリーンスタートアップの後、InnoDBは「クラッシュリカバリ」を実行しました。innodb_force_recovery = 4のビジネスを行って、ハングしたMyISAMテーブルを修復しました。これで、レプリケーションの準備が整いました。大きな数字を表明： 111116 15:49:36 InnoDB: Error: page 393457 log sequence number 111 561,760,232 InnoDB: is in the future! Current system log sequence number 70 3,946,969,851. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: …

16 mysql  innodb 

この質問は、この以前の投稿と、次のように復元された将来の調査のためにデータベースを提出したことによって促されました。 BACKUP 'BrokenDatabase' detected an error on page (1:123456) in file ’BrokenDatabase.mdf'. Error: 3043, Severity: 16, State: 1. リンクされた質問とDBCC PAGE調査の準備ができているバックアップでは、DBCC CHECKDBはエラーなしで合格しましたが、破損が明らかに存在します。 CHECKDBはパスするがBACKUP WITH CHECKSUMは失敗することにより、どのような種類の破損が発生する可能性がありますか？

16 sql-server-2008  sql-server-2005  dbcc  corruption 

MyISAMからInnoDBに変換したいかなり小さなデータベースがあります。データベース初心者であるため、サイトをダウンさせることなく変換（alter tableを使用）しました。 変換が完了したので、多くの断続的な行が欠落しているようです。これは、おそらく変換中の操作によるものですか？または、問題はどこか別の場所ですか？

16 mysql  innodb  myisam 

誰でもdbシャーディングを教える本の良い推薦書を持っていますか（せいぜいゼロから） シャーディングについて話している40の異なるWebサイトを読みました。 私はオンラインサイト/ブログがお粗末だと言っているのではありません、彼らは良い力です。しかし、私はメインの食事が必要なだけでなく、あちこちで有用な情報が必要です。基本的に、シャーディングを実装する方法についてのアイディアはあると思いますが、それは非常に複雑な概念であるため、研究できるものはもっとたくさんあります。

16 mysql  sql-server 

運用の一環として、多数のファイル/ディレクトリを追跡する必要がある製品を開発しています。アイデアは、統計情報をデータベースに保存し、ブート時に各ファイルのウォッチを作成することです。変更されたファイルは、リモートデータベースへのグループ同期のために（データベース内で）キューに入れられます。それらは優先順位の順に同期され、1から10の間の数値になります。 データベースに関する情報： <100,000エントリの統計情報 起動時にデータベース全体が読み込まれ、ファイルパスのみが必要です キューに入れられたファイルには優先度フィールドがあります（他に何も検索する必要はありません） 挿入が遅い場合があります うまくいくと思うデータベースをいくつか見つけましたが、どちらが最適かはわかりません。 Redis-ファイルパスをキーとして、統計データを値として保存。キューはリストになります MongoDB -Redisよりも多くのクエリオプションがありますが、それでも高速です ここでは、リレーショナルロジックが多すぎず、合計データサイズが大きすぎない（100 MB未満、30 MB未満に近い）NoSQLデータベースが最適なソリューションになると考えています。SQLiteは、インストール可能なアプリケーションに組み込むのに十分なほど単純だと思われるため、SQLiteを検討しました。 これはエンドユーザー向けの分散アプリケーションであり、高負荷サーバーではないため、データベースは多くの同時ユーザーをサポートする必要はありません。ここでの最優先事項は、モデルが最も意味のあるデータベースを見つけることです。 それでは、この状況に最も適したデータベースはどれですか？ また、このようなアプリケーションにとってより意味のある他のデータベースはありますか？

16 database-recommendation 

他のデータベース設計者と正規化について興味深い議論をしています。この例では、GameTitlesテーブルがあり、各レコードにはゲームがリリースされた年が含まれている必要があります。彼は、2NFはすべてを正規化することを義務付けているので、準拠するには、GameTitlesテーブルによって参照される独自のプライマリキーを持つYearYフィールドをReleaseYearsテーブルに分割する必要があると言います。GameTitlesテーブル自体のフィールドとして残す必要があると言います。 これに対する私の主張は、年はその性質上静的な単なる非プリミティブ数値であるということです（つまり、2011は常に2011です）。このため、独自の識別子として機能し、それが何であるかを参照する必要はありません。また、テーブルを参照するためだけに新しい年をテーブルに追加する必要があるため、追加のメンテナンスも導入されます。テーブルに長い年数を事前に入力すると、それらへの参照をまったく持たない可能性のある追加のレコードがあります。これにより、余分なテーブル、レコードのオーバーヘッド、および年自体の追加の主キーがあるため、データベースサイズも増加します。GameTitlesテーブルのフィールドとして年を保持すると、この追加のメンテナンスとオーバーヘッドがすべてなくなります。 これについての考え？ 編集： StackOverflowでこれを投稿することを意味します。誰かがこれを削除するか、注意を喚起するために投票できますか？

16 normalization 

実行中のストアドプロシージャに関するフィードバックを求めることができるかどうか、およびシナリオを処理するより効率的な方法があるかどうか疑問に思うだけです（きっとあるはずです！）。 基本的に、1つ以上のステータスと並べ替え順序を持つ可能性のあるレコード（ジョブ）のリストを返すために呼び出す単一のSPがあります（ページングにRowNumを使用しています）。現時点では、ステータスの変化は常に変化する可能性があるため（ユーザーなどによって）、WITH RECOMPILEを使用しています。いくつかのフィルタリングも行われています。 IFステートメントを使用して、本質的に同じビットのコードを実行し、唯一の変更はソート順です。 私の質問は次のとおりだと思います：これを行うためのより良い方法はありますか（おそらく、ステータスごとに異なるSP）。知識不足のために物事を複雑化しすぎていますか（かなりありそうです）SPは実際には問題ありませんが、行数を減らすために微調整が必​​要ですか？ 以下のSPの一部を貼り付けました-完全なコードとの唯一の違いは、異なる並べ替え順序の追加のIFステートメントです... フィードバックをお願いします。 前もって感謝します！ PROCEDURE [dbo].[sp_Jobs] @PageNumber int, @PageSize int, @FilterExpression varchar(500), @OrderBy varchar(50), @CustomerID int, @ShowNotSet bit, @ShowPlaced bit, @ShowProofed bit, @ShowReProofed bit, @ShowApproved bit, @ShowOnTime bit, @ShowLate bit, @ShowProblem bit, @ShowCompleted bit, @ShowDispatched bit, @ShowUnapproved bit, @ShowClosed bit, @ShowReturned bit, @UserID int WITH RECOMPILE …

16 sql-server-2008  stored-procedures 

アカウントで収集するための1日のコストを追跡する何かを作成するように求められ、これをサポートするデータベーステーブルスキーマを見つけようとしています。 これが私が知っていることです 会社は250万以上のアカウントを持っています これらのうち、彼らは現在、1か月あたり平均20万人働いています（現在は低い人員配置レベルで変化します） 追跡したい13の異なるコストタイプがあり、将来さらに追加する可能性があると警告しています。 コストを毎日追跡したい コストは在庫全体に分割されません。それらは、1か月あたり働くアカウント数（200,000）に分割されるか、ユーザーがアカウント識別子を入力してアカウントのグループにコストを適用するか、単にコストを適用するアカウントを指定できます。 最初に考えたのは、正規化されたデータベースです。 アカウントID 日付 CostTypeId 量 これに関する私の問題は、数学をすることです。このテーブルはすぐに巨大になります。13のすべてのコストタイプが今月のすべての作業済みアカウントに適用されると仮定すると200k * 13 * N days in month、これは1か月あたり約7500〜8000万レコード、または1年あたり約10億レコードになります。 私の2番目の考えは、それを少し非正規化することでした アカウントID 日付 総費用 CostType1 CostType2 CostType3 CostType4 CostType5 CostType6 CostType7 CostType8 CostType9 CostType10 CostType11 CostType12 CostType13 この方法はより非正規化されており、1か月あたり最大600万レコード（200k * N days in month）、または1年あたり約7,200 万レコードを作成できます。最初の方法よりもはるかに少ないですが、将来会社が新しいコストタイプを決定した場合は、別のデータベース列を追加する必要があります。 2つの方法のうち、どちらがお好みですか？どうして？これをより良く処理できると考えられる別の選択肢はありますか？ 私は、要約レポートと詳細レポートの両方のパフォーマンスのレポートに最も興味があります。アカウントに費用を配分するジョブは、誰もいないときに夜間に実行されます。二次的な懸念は、データベースのサイズです。既存のデータベースはすでに約300 GBであり、ディスク上のスペースは約500 GBであると思います。 データベースはSQL Server …

16 sql-server  performance  database-design 

単一のSQLコマンドでPostgreSQLを実行すると、予想どおりエラーコードが返されます。 % psql -c "SELECT * FROM AWDASDASDASDAS" my_db ERROR: relation "awdasdasdasdas" does not exist LINE 1: SELECT * FROM AWDASDASDASDAS % echo $? 1 しかし、ファイルを実行すると、エラーは抑制されます。 % psql -f test.sql my_db psql:test.sql:1: ERROR: relation "awdasdasdasdas" does not exist LINE 1: SELECT * FROM AWDASDASDASDAS % echo $? 0 これらのエラーを取り戻す方法はありますか？

16 postgresql