データベース管理者

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

1
PostgreSQLおよびMySQLのスケーラビリティの制限
MySQLやPostgreSQLなどの非シャードリレーショナルデータベースのパフォーマンスは、10 TBを超えると「壊れる」と聞きました。 Netezza、Greenplum、Verticaなどでは思いつかないような制限が存在するのではないかと思いますが、これらの制限が定量化されている研究論文や正式なケーススタディに言及している人がいるかどうかを尋ねたいと思います。

9
トランザクションを使用せず、回避策を使用して1つをシミュレートするように要求
私は数年間T-SQLを開発してきましたが、常に掘り下げて、言語のすべての側面についてできる限りのことを学び続けています。私は最近新しい会社で働き始め、取引に関して奇妙な提案だと思うものを受け取りました。それらを使用しないでください。代わりに、トランザクションをシミュレートする回避策を使用してください。これは、1つのデータベースで多くのトランザクションを処理し、その後多くのブロッキングを行うDBAによるものです。私が主に作業しているデータベースはこの問題の影響を受けず、トランザクションは過去に使用されたことがあります。 トランザクションはブロックすることが本来の性質であるため、トランザクションでブロックすることが期待されていることを理解しています。しかし、各ステートメントが正常に実行されなければならない場合が多くあります。1つが失敗した場合、それらはすべてコミットに失敗する必要があります。 私は常にトランザクションの範囲をできる限り狭く保ち、常にSET XACT_ABORT ONと組み合わせて使用​​し、常にTRY / CATCH内で使用しています。 例: CREATE SCHEMA someschema; GO CREATE TABLE someschema.tableA (id INT NOT NULL IDENTITY(1, 1) PRIMARY KEY, ColA VARCHAR(10) NOT NULL ); GO CREATE TABLE someschema.tableB (id INT NOT NULL IDENTITY(1, 1) PRIMARY KEY, ColB VARCHAR(10) NOT NULL ); GO CREATE PROCEDURE someschema.ProcedureName @ColA …

1
ダウンタイムなしでのスキーマ変更とライブデータベースへのデータ移行のベストプラクティス
ダウンタイムなしでライブデータベースのスキーマをどのように変更しますか? たとえば、すべてが特定のユーザーに関連付けられている、メールアドレスなどのさまざまなユーザーデータを含むテーブルを持つPostgreSQLデータベースがあるとします。電子メールアドレスを新しい専用テーブルに移動する場合は、スキーマを変更してから、電子メールデータを新しいテーブルに移行する必要があります。元のテーブルへの書き込みを停止せずにこれを行うにはどうすればよいですか?確かに、古いテーブルから新しいテーブルにデータが上書きされる間、新しいデータは引き続き古いテーブルに書き込まれ、失われますよね? この問題はかなり頻繁に発生すると思いますが、それを処理するための標準的なソリューションが見つかりません。 この記事ではこの問題を扱いますが、手順3を本当に理解していませんでした。彼は両方のテーブルに書き込み、古いデータを最初のテーブルから新しいテーブルに移行するように言っています。古いデータのみを移行していることをどのように確認しますか? (HerokuでPostgreSQLを使用しています。)

5
データベースを縮小しても大丈夫ですか?
シュリンクは悪魔です。ページの順序を逆にし、皮膚がん、データの断片化、地球温暖化の原因となります。リストは続きます...つまり、100 GBのデータベースがあり、50 GBのデータを削除するとします。1つのテーブルではなく、データベース全体のレベルで古いデータを削除し、90%をカバーします。テーブル-これはデータベースを縮小するための適切なユースケースを構成しますか? そうでない場合、データベースからこのような高い割合のデータを削除した後に家をきれいにするために取る適切な手順は何ですか?インデックスの再構築と統計の更新の2つを考えることができます。ほかに何か?

5
SQL Serverメンテナンスプラン-タスクとスケジューリングのベストプラクティス
私は、SQL Server 2005データベースのメンテナンスプランを考案する必要があります。バックアップについては、毎日15分ごとにデータベースの完全バックアップとトランザクションログバックアップを行いたいと考えています。私が抱えている問題は、他にどのようなタスクをやりたいのか、どのくらいの頻度でそれらを行うべきなのかを把握することです。 それで、これまでのところ私はこれを念頭に置いています。私の考えに欠陥がある場合、またはこれを行うためのより良い方法がある場合は、私を修正してください。 バックアップ-すべてのテーブル、フルバックアップ(毎日) バックアップ-選択したテーブル、フルバックアップ(1時間ごと) バックアップ-トランザクションログ(15分ごと) データベースの整合性を確認する(毎日) インデックスの再編成(毎日) 統計の更新(毎日) データベースの縮小(毎週) インデックスの再構築(毎週) メンテナンスクリーンアップ(毎日) これらのタスクの一部は毎日実行する必要がないか、毎日実行するべきではないことを少し前に(別のジョブで同様の計画を設定したとき)読んだことを思い出しました。どのものに関しては、それは私を免れます。災害時のデータ損失を削減するより良いメンテナンスプランを作成するための少しのガイダンスを使用できますが、ピーク時の実行時にシステムに負担をかけません(そしてパフォーマンスも向上します)。

9
MySQL用のMicrosoftの「SQL Server Profiler」のようなツールはありますか?[閉まっている]
MySQLでの開発中に、プロファイラーを起動できないことが本当に残念です。私が見つけSQLyogのは、クエリアナライザのための良い十分な代替品ですが、SQLプロファイラのような働きツールを発見していません。 MicrosoftのSQLプロファイラーを見たことがないMySQLの人向けに、ここにスクリーンショットがあります 私の以前の仕事では、SQLプロファイラに勝るツールがあり、スタックトレースも提供していました。 私が言及したようなMySQLで動作するツールを知っている人はいますか? (参考までに、MySQLでAltiris Profilerを使用することはできますが、Windowsを実行する必要があります。さらに、Symantec skuではないため、ライセンスは非常に複雑です)
43 mysql  profiler  tools 

2
MySQL:テーブルに関連する外部キーを確認する方法
MySqlのテーブルに関連する外部キーを表示する方法は? 背景:外部キー制約を持つテーブルをMySqlにドロップしたかった。私がそれをするとき、私はこれを得る: Error Code: 1217. Cannot delete or update a parent row: a foreign key constraint fails 他のテーブルを残すテーブルに関連する外部キーを削除するにはどうすればよいですか。


3
現在のデータベースメール構成を確認するにはどうすればよいですか?
SQL Server(2008)インスタンスはメールを送信するように構成されており、すべてが正常に機能していますが、既存の構成、特にSMTPサーバーを表示する方法がわかりません。 SSMSからは、構成ウィザードのみを起動でき、オンラインでは何も見つかりません。設定方法に関する多くの情報がありますが、現在の設定の表示方法に関する情報はありません。 既存の設定を表示するにはどうすればよいですか?

5
SQL Serverでのデータの難読化
SQL Serverでのデータ難読化のベストプラクティスは何ですか? UATシステムでマスクされた生産データを使用したいと思います。 より迅速に、より高いレベルの難読化でそれを行いたい場合、どのようなアプローチをとるべきですか?人々の名と姓のスクランブルについて考えていますが、どうですか?自分で関数を作成する必要がありますか、それとも使用可能な定義済み関数がありますか?車輪の再発明に時間をかけたくありません:) 日付フィールドはどうですか?たとえば、生年月日をテーブル全体からランダムに選択してレコードに割り当てる必要がありますか、それとももっと良い方法がありますか?

4
通信パケットの読み取りMySQLエラー
MySQLエラーログでは、次のような警告がかなり表示されます。 120611 16:12:30 [Warning] Aborted connection 2619503 to db: 'db_name' user: 'user_name' host: 'webapp_hostname' (Got an error reading communication packets) データ自体の損失に気付いていないので、この警告が何を意味するのか、それが何を引き起こすのか、そしてこれらを引き起こす問題にどのように対処するのか疑問に思います。これは、RHEL 6.1およびMySQL Enterprise 5.5にあります。
42 mysql  mysql-5.5 

2
統計を更新するタイミング
以下を行うメンテナンスプランを継承しました。 古いデータをクリーンアップする DBの整合性をチェックします データベースとトランザクションログのバックアップを実行します インデックスを再編成します 統計の更新 古いバックアップとメンテナンスプランファイルを削除する 23分間のメンテナンスプランのうち、統計の更新には13分間という驚異的な時間がかかります。この13分間、データベースへのアクセスはブロックされます(または、少なくとも、このDBから他のデータベースへのレプリケーションは一時停止されます)。 私の質問は: 統計をいつ更新する必要がありますか? これは、毎日よりも頻繁に行うべきではないように思えます。私は、不必要なメンテナンスを行うという「理由」の考え方から抜け出そうとしています。

5
ネストされたビューは優れたデータベース設計ですか?
私はずっと前にどこかで読んだことがあります。この本は、SQL Serverでネストされたビューを持つことを許可すべきではないと述べています。私たちがそれができない理由がわからないか、間違った記述を覚えているかもしれません。 学生 SELECT studentID, first_name, last_name, SchoolID, ... FROM students CREATE VIEW vw_eligible_student AS SELECT * FROM students WHERE enroll_this_year = 1 先生方 SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers CREATE VIEW vw_eligible_teacher AS SELECT * FROM teachers WHERE HasCert = 1 AND enroll_this_year = 1 学校 CREATE …

5
ソートされたリストを保存するためのデータベースを設計する方法は?
データベース内にソートされたリストを保存したいと思っています。次の操作を効率的に実行したい。 Insert(x)-レコードxをテーブルに挿入します Delete(x)-テーブルからレコードxを削除します Before(x、n)-ソートされたリストでレコードxの前にある 'n'レコードを返します。 After(x、n)-ソートされたリストのレコードxに続く 'n'レコードを返します。 First(n)-ソートされたリストから最初の 'n'レコードを返します。 Last(n)-ソートされたリストから最後の 'n'レコードを返します。 Compare(x、y)-テーブルの2つのレコードxとyが与えられ、x> yかどうかを見つけます。 私が考えることができる簡単な方法は、ある種の「ランク」属性をテーブルに保存し、その属性でソートすることでクエリすることです。ただし、この方法では、ランク付きのレコードの挿入/変更はコストのかかる操作になります。より良い方法はありますか? 具体的には、AmazonのSimpleDBを使用してテーブルを実装することを検討しています。ただし、リレーショナルデータベースの一般的な回答も役立つはずです。 負荷プロファイルの更新: これはWebアプリケーション用に計画しているので、アプリを使用するユーザーの数に依存します。 10万人のアクティブユーザーがいる場合(スーパーオプティミズム:P)、1日あたりの私のおおよその見積もりは 50万の選択、10万の挿入と削除、50万の更新 テーブルは合計で500kまで成長すると予想されます。 更新、挿入、および比較の操作を最適化しようとしています。アイテムのランクは常に変化するため、テーブルを更新し続ける必要があります。

7
データベース開発にSSMS経由でVisual Studio 2010を使用する必要があるのはなぜですか?
Visual Studio 2010では、データベースプロジェクトと、データベース開発を促進すると思われる関連機能が多数導入されています。私は長年にわたってSQL Server Management Studio(SSMS)を使用して、問題なくデータベース開発を行ってきました。 SSMSが機能するのに、なぜVS2010を使用する必要があるのですか?具体的には、SSMSよりも優れているのは何ですか? しかし、おそらく私の前提は間違っており、SSMSは依然としてデータベース開発のVSに勝っています。もしそうなら、それはどのような特定の方法で本当ですか?

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