データベース管理者

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

1
全文索引とスカラーインデックスの組み合わせ
たとえば、全文を使用して検索できる必要のある1200万人の名前と住所のデータベースがあるが、各行には整数値も含まれているとしCOMPANYIDます。テーブルには、1,200万行を超える約250の個別のCOMPANYIDが含まれています。 フルテキストインデックスを定義するときCOMPANYに、ツリーにそれぞれ独自の「ブランチ」を与えることは可能ですか?

1
最新のサーバーでのパフォーマンスの低下
実稼働環境にはいくつかのdbサーバーがあり、そのうち4つはハードウェア構成が非常に似ています。Dell PowerEdge R620、唯一の違いは、最新の2つ(3か月前に購入および構成されたもの)にRAIDコントローラーv710、256GB RAM、およびCPUが2つの物理Xeon E5-2680 2.80GHzであることです。古いもの(約1年前に購入および構成されたもの)には、RAIDコントローラーv700、128GB RAMがあり、2つの物理Xeon E5-2690 2.90GHzで実行されています。BIOSの更新、すべてのドライバーの最新バージョンへの更新など。実行中のすべてのSQL Server 2008R2 Enterprise(SP1)が最新のCUおよびWindows 2012R2 Standardに更新されました。どちらも200 GB SSD x5 RAID10で動作します。それぞれで実行されているデータベースは1つだけで、SSISパッケージを呼び出すジョブを使用して同期されます。私たちのシステム管理者は、ハードウェアやネットワークの設定ミスや失敗がないことを確認するために、多くのパフォーマンスとストレステストを実行しました。予想通り、最新のものはより良いパフォーマンス結果を示しています。ここまでは順調ですね。 私たちが抱えている問題は、Kibanaの画面キャプチャーで確認できます。黄色とオレンジは2つの新しいサーバー(テーブルでは6、7)で、他のすべてのサーバーの下にあります。これらの2つの新しいサーバーの応答時間が遅いことが完全にわかります。それだけでなく、これらの2つのサーバーの負荷も、2つの古いサーバーよりもわずかに少なくなっています(表の淡い青色と濃い青色の線-4,5)。 パフォーマンスカウンターに関する情報を収集するいくつかの監視スクリプトを用意します。DMVと3番目の監視ツールで可能な限り掘り下げたので、私は多くの情報を手元に持っています。しかし、この遅い応答時間に対する答えを見つけることができないため、ここで見逃していることがあるはずです。 最新の2台のサーバーはRAMの使用量が少ないですが、他の古いサーバーと比較すると、負荷が低いため、それは予想通りです。 | Server Name| Mem_MB | Mem_GB | Server_RAM_GB | SQL_max_mem_GB| SQL_min_mem_GB | |------------|--------|--------------|---------------|---------------|----------------| | 4 | 41108 | 40.145263671 | 128 | 120 | 16 | | 5 | …

3
Microsoft SQL Serverのベンチマーク方法
私の会社では、SQL Server 2008 R2をホストする複数の仮想マシンを使用しており、一部のマシンは他のマシンとは異なる動作をします。NASへの接続が遅いためにVmwareホストが非常にビジーなためです。 テストSQLデータベースでSQLコードを実行する方法、または各VMのベースライン/ベンチマークパフォーマンスでいくつかのパフォーマンステストを実行するために使用できる既知のベストプラクティスを実行できる方法はありますか?これらのマシンをProdまたはUAT環境に?ありがとう、Davide。

1
MySQLレプリケーション:マスターの後ろの超高音
本番データベース用にスレーブdbサーバーをセットアップしましたが、show slaveステータスを確認したところ、マスターの数秒後に非常に大きな数値が表示されました。 これは出力です: Slave_IO_State: Waiting for master to send event Master_Host: 1.2.3.4 Master_User: replicator Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000173 Read_Master_Log_Pos: 15909435 Relay_Log_File: mysqld-relay-bin.000079 Relay_Log_Pos: 91173356 Relay_Master_Log_File: mysql-bin.000093 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 91173210 Relay_Log_Space: 8179978166 Until_Condition: None Until_Log_File: …

1
PostgreSQLストリーミングとファイルベースのレプリケーション(サーバーの動作と構成の観点から)
本番環境でトラブルシューティングできるように、PostgreSQLレプリケーションの最適な使用法とその仕組みを理解しようとしています。 これらの2種類のレプリケーションの違いを(1)構成(2)2つのサーバーのマスター/スレーブが各シナリオでどのように実行するかという点を理解するのに苦労しています PostgreSQL(9.2以降)でのレプリケーションは、基本的にサイズが16MBのXLOGファイル(各ファイルを作成するための周波数設定に依存)がマスターで作成され、なんらかの方法でスレーブに送信されます。 私の設定(この質問の目的のため) マスターarchive_command = 'rsync -av%p postgres @ [SlaveIP]:[wal_archive_folder] /%f' 上のPostgresql.confの設定 ログファイルを読み取るためのスレーブ上のRecovery.confの構成 restore_command = 'cp [wal_archive_folder] /%f \ "%p \"' primary_conninfo = 'host = [MasterIP] port = 5432 user = postgres' 私の質問は、この構成のどの部分がこの「ストリーミング」レプリケーションと「ログシッピング」を作るのかということです。私のマスターは、rsyncを使用してスレーブにログを送信するように構成されています(これはログ配布ですか?)私のスレーブは、recovery.confでマスターに接続できるように構成されています(これはストリーミングですか?) 質問の後半:何が起こっているのですか?WAL_senderとWAL_receiverを介してPostgreSQLに別のプロトコルがあることを理解しています。しかし、これがストリーミングのみに使用されているかどうかは不明です。使用されている場合、マスターでrsyncはどのように使用されていますか? :) ありがとうございました!!そして、これが明らかな質問であれば申し訳ありません。私はブログや本をたくさん読んでいますが、理解に苦労しています。Postgres wikiは非常に詳細なので、すべてを完了するには長い時間がかかります(そして私には期限があります)

2
sys.dm_db_index_usage_statsの情報は信頼できるか
ドキュメントがない古いシステムのデータをアーカイブしています。私は幸運... テーブルが作成された日時、最後にアクセスされた日時などを確認したいのですが、このクエリで正しい答えが得られると信頼できますか、それとも最初に確認する必要があるパラメータがありますか?SQL Server 2008 R2: SELECT t.Name AS Tabelname, p.rows AS NoOfRows, MAX(us.last_user_lookup) AS LastUsed, t.create_date AS CreatedDate FROM sys.tables t INNER JOIN sys.indexes i ON t.OBJECT_ID = i.object_id INNER JOIN sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id LEFT JOIN --A lot of the tables did not …

1
2つのサーバーでのMySQLのパフォーマンスの大きな違い
MySQLサーバーをテストサーバーと本番サーバーの2つの異なるマシンにインストールしました。どちらもWindowsであり、ウェブアプリケーションで使用されます。 問題は、いくつかのクエリを実行すると、2つのマシン間でパフォーマンスが大幅に異なることです(本番サーバーの方が低速です)。両方のサーバーのMySQLバージョンは同じです。構成ファイルも同じです(唯一の違いは、データのパスと、運用サーバーがエラー以外のログを記録しないことです)。私が話しているパフォーマンスの違いは3桁または4桁大きくなっています(たとえば、テストサーバーでのクエリは0.2秒で実行されますが、運用サーバーでは84秒で実行されます)。 問題のクエリは、 "WHERE [...] IN [...]"を含む句を多用しています。これは、通常非常に遅く、JOINに置き換える必要があることを理解しています。ただし、使用しているMySQLのバージョンは5.6.19であり、これらのクエリは自動的に最適化されます。そのため、テストサーバーではクエリが高速に実行されます(変更できないプログラムの一部であるため、手動で最適化することはできません)とにかく)。 先ほど述べたように、MySQLのインストールと構成は同じであるため、問題がどこにあるのかはまったくわかりません。一方では、プログラムとDBが同じであるため、なんらかの構成上の問題である必要があると思いますが、一方で、構成が同一であるため、これは意味がありません。 サーバー上のデータ: テストサーバー: Intel Core 2 Quad Q9400 @ 2.66GHz 8GB RAM Windows Server 2008 R2スタンダード 本番サーバー: Intel Xeon E5530 @ 2.40GHz 5GB RAM Windows Server 2012 R2スタンダード 編集:重要なことを言うのを忘れていました。「問題の」クエリとは別に「WHERE ... IN」句を使用するクエリが実行されています。これらは両方のマシンで高速に実行され、MySQLによって正しく最適化されていることを示唆しています。他のクエリが最適化されていないときに最適化されているクエリがあるのは不思議です。これが実際の問題であるかどうかは不明です。 編集#2:両方のサーバーの構成ファイルは次のとおりです:http : //pastebin.ca/2834906 編集#3:遅いクエリの1つ のEXPLAINは次のとおりです。https://mariadb.org/ea/v36zj EXPLAINは、テストと製品の両方でまったく同じです。クエリ自体はこちらです:http : //pastebin.com/VXgBxXmtこれはオートフォーマッタでフォーマットされているため、あまり明確ではありません。ご覧のとおり、は非常に長く複雑です。これは手動で生成されたものではなく、いくつかの機能を備えた標準SQLの方言を使用するソフトウェアによってさらに自動的に生成されます。 また、詳細情報:本番サーバーのデータを減らし、使用されないDBの古いデータのほとんどを削除することで、一時的に問題にパッチを適用しました。もちろん古いデータも必要なので、これは解決策ではありません。将来的には問題になるでしょう。DBはそれほど大きくありません。完全なDBは1308MBで、現在生産中の縮小バージョンは332MBです。 更新:解決しましたか? 私は問題を解決したと思います。本番サーバーが実際に使用されているため、まだテストしていませんが、考えられる問題は、182Mに設定されたパラメーター "innodb_buffer_pool_size"でした。実際には、構成ファイルの行は次を示しています:innodb_buffer_pool_size …

1
MongoDBでホストごとの接続を制限するにはどうすればよいですか?
私は、javaドライバーを介して他のクライアントからの接続を受け入れるmongoサーバーを実行しています。私が気づいたのは、しばらくすると一部のユーザーが開いているポートが多すぎるため、他のユーザーがmongoに接続できなくなることです。1つのmongoClientオブジェクトのみを作成しますが、IPをチェックすると数百のポートが監視されます。 Javaドライバーでホストごとの接続を制限する例に出くわしましたが、クライアントにそれを混乱させたくありません。mongodインスタンスからクライアントを制限するにはどうすればよいですか? インスタンスは、Linuxリモートサーバー上で実行される1つのmongodです。

1
日付ディメンションテーブルにデータを入力するための最適な方法
SQL Server 2008データベースに日付ディメンションテーブルを設定することを検討しています。テーブルのフィールドは次のとおりです。 [DateId] INT IDENTITY(1,1) PRIMARY KEY [DateTime] DATETIME [Date] DATE [DayOfWeek_Number] TINYINT [DayOfWeek_Name] VARCHAR(9) [DayOfWeek_ShortName] VARCHAR(3) [Week_Number] TINYINT [Fiscal_DayOfMonth] TINYINT [Fiscal_Month_Number] TINYINT [Fiscal_Month_Name] VARCHAR(12) [Fiscal_Month_ShortName] VARCHAR(3) [Fiscal_Quarter] TINYINT [Fiscal_Year] INT [Calendar_DayOfMonth] TINYINT [Calendar_Month Number] TINYINT [Calendar_Month_Name] VARCHAR(9) [Calendar_Month_ShortName] VARCHAR(3) [Calendar_Quarter] TINYINT [Calendar_Year] INT [IsLeapYear] BIT [IsWeekDay] BIT [IsWeekend] …

1
BLACKHOLEテーブルからデータを回復することは可能ですか?[閉まっている]
閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか? 質問を更新して、データベース管理者のスタック交換のトピックになるようにします。 5年前休業。 エンジンBLACKHOLEを使用してテーブルを作成しました。 基本的に、BLACKHOLEストレージエンジンは、データを受け入れますが、破棄して格納しない「ブラックホール」として機能します。検索は常に空の結果を返します。 innodbまたはmyisamとしてストレージエンジンを使用して、古いテーブルと同じ新しいテーブルを作成することでデータを取得できると聞きました。しかし、私もそれを試しましたが、結果を得ることができませんでした。誰かがこの問題を解決するために私を助けることができますか? mysql> CREATE TABLE test1(i INT, c CHAR(10)) ENGINE = BLACKHOLE; Query OK, 0 rows affected (0.08 sec) mysql> INSERT INTO test1 VALUES(1,'record one'),(2,'record two'); Query OK, 2 rows affected (0.00 sec) Records: 2 Duplicates: 0 Warnings: 0 mysql> select * from test1; Empty …

1
インデックスは、個別のSELECTと比較してOR条件を使用するとはるかに遅くなります
これらの質問と与えられた回答に基づいて: SQL 2008 Server-非常に大きなテーブルに接続されている可能性があるパフォーマンスの損失 履歴データを含む大きなテーブルは、SQL Server 2008 Stdを過剰に割り当てます。メモリ-他のデータベースのパフォーマンス低下 データベースSupervisionPに次のように定義されたテーブルがあります。 CREATE TABLE [dbo].[PenData]( [IDUkazatel] [smallint] NOT NULL, [Cas] [datetime2](0) NOT NULL, [Hodnota] [real] NULL, [HodnotaMax] [real] NULL, [HodnotaMin] [real] NULL, CONSTRAINT [PK_Data] PRIMARY KEY CLUSTERED ( [IDUkazatel] ASC, [Cas] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS …

1
クラスター化された複合キーを持つテーブルでの「大きな」挿入中に何が起こりますか?
私のSQLの知識は限られているので、私が使用する用語はおそらく正しいものではありません。 複数の場所のテスト結果を格納するテーブルがあります。 テストは異なる場所(ネットワーク接続なし)の異なるデータベースに記録され、「マスター」場所は他の場所から定期的にテスト結果を「インポート」します。 LocationId(int)列とDate(datetime)列にこの順序でクラスター化された複合主キーを配置する予定です。その理由は、ロケーションのすべての結果を一緒に保持する必要があるためです。日付範囲ではなく、日付範囲とロケーションでクエリを実行することはほとんどありません。 行のサイズは80〜100バイトで、テスト結果の数は数百万を超えてはなりません。通常の「インポート」では、別の場所から50〜10万の結果が挿入されます。 インポート中に何が起こりますか?SQLはクラスタリングを維持するために既存の行を「移動」しますか、それともテーブルを「断片化」させますか?インポートが一度に1行ずつ実行されると、パフォーマンスに大きな影響を与える可能性がありますか?行の順序を気にせず、ID列を主キーとして追加し、日付列にインデックスを追加してクエリを支援する必要がありますか?

2
使用されていないがクエリに影響を与えるインデックス
いくつかの数値といくつかの追加データを含むPostgreSQL 9.3テーブルがあります。 CREATE TABLE mytable ( myid BIGINT, somedata BYTEA ) このテーブルには現在約1,000万のレコードがあり、1GBのディスク容量を使用します。myid連続していません。 100000の連続番号の各ブロックにある行の数を計算したいと思います。 SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000; これは約3500行を返します。 クエリプランでまったく言及されていなくても、特定のインデックスが存在すると、このクエリが大幅に高速化されることに気づきました。インデックスなしのクエリプラン: db=> EXPLAIN (ANALYZE TRUE, VERBOSE TRUE) SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------- GroupAggregate (cost=1636639.92..1709958.65 …

2
PostgreSQL 8.4でインデックスを再作成する前に、常にVACUUM ANALYZEを行う必要がありますか?
毎日早朝にpgAgentジョブがPostgreSQL 8.4データベースのテーブルBからテーブルAの内容を更新します。テーブルAには、91列にまたがる約140kのレコードが含まれ、2つのインデックスがあります。1つはPRIMARY KEYの一部として、もう1つはPOINT PostGISジオメトリ列のGISTインデックスです。 プロセスを少し速くするために、ジョブはテーブルAのレコードを削除してテーブルBからレコードを挿入する前に、ジオメトリ列のインデックスを削除し、その後インデックスを再作成します。これがすべて完了すると、autovacuumデーモンは、希望どおりに動作するようになります(ジョブの統計情報とテーブルの統計情報をジョブの完了時間とautovacuumの実行時間と比較して10分ほど後)。 これがすべて起こった後の今朝のテーブルのチェック時に、テーブルの統計から、テーブルサイズは272MB、TOASTテーブルサイズは8192バイト、インデックスサイズは23MBであることがわかりました。これはかなり大きいように見えたので、テーブルにREINDEXコマンドを発行し、インデックスサイズは9832kBになりました。 私の質問はこれです: インデックス(または少なくともジオメトリ列インデックス)を最初から作成したときに、REINDEXがインデックスのサイズを大幅に削減するのはなぜですか?インデックスが作成される前に、テーブルがバキューム/分析されていることを確認する必要がありますか?主キーのインデックスを削除することがこれの要因ではありませんか?何が欠けていますか?

1
SQL Serverでの低速なDELETEに対して要求された説明
SQL Serverの削除動作に関する追加の洞察/推論を取得したいと思います。1800 GBを超えるかなり大きなデータベースがあります。 数百万行の非常に浅いテーブル(少数の整数列のみ)があります。これらの浅いテーブルから10,000の行を削除する場合、削除クエリは一般に非常に高速です(多くても数秒)。 また、image平均100 KBの画像を保存するタイプのフィールドを持つテーブルもあります。このテーブルから数千行しか削除しない場合、1分以上かかります。 違いは明らかですが(サイズの点ではるかに多くのデータが削除されます)、SQL Server内で何が起こるかについてもっと知りたいと思っています。後者の削除が非常に遅くなることをよりよく理解できるように。 誰かが光を当ててくれますか?

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