データベース管理者

ですから、これは今年のダミーの質問になりますが、これを通過するのは初めてではないので、尋ねる必要があります。次のテーブル定義を見てください。 今すぐですが、電話番号が表示される列from_numberを見てくださいVARCHAR(45)。電話が世界中でいくつの番号を持つことができるかわからないので、私はそれらのほとんどすべてをカバーしようとしています。私は私が考えるように、可能な限り、データベースの整合性を維持したいVARCHARあなたは私に言う、多分私は間違っている- -私はへの変更に考えていますので、この種の情報ホールドのための適切なタイプではありませんINT偶数かBIGINT。 Workbenchで列を定義するとき()は、すべての場合ではなく、前に言及したものの中で括弧で囲まれた数を指定する必要があります。だから私がこれを行うと：BIGINT()私はこのエラーを受け取りました： ここで、このMySQLタイプについて少し読んでください。基本的に情報はこれです： 大きな整数。...符号なしの範囲は0〜18446744073709551615です。 それは私に尋ねます：BIGINT()型を定義するときに括弧に設定する値。（私はBIGINTを使用していますが、これはINTが電話が持つことができる数と同じ数を保持できるかどうかわからないためです-おそらく私も間違っています）。MariaDB / MySQLデータベースに列を作成する正しい方法はどれですか？ とにかく私はあなたの意見、経験を知りたいです、そして、もちろん、私は答えを得たいです 注： ER図の作成には、MySQL Workbench最新版を使用しています。MariaDB 10.0.xも使用しています

12 mysql  mariadb  datatypes 

だから、タイトルはそれを要約しています。 28個のテーブルと86個のストアドプロシージャを備えたSQL Serverデータベースがあり、リバースエンジニアリングする必要があります。一部のテーブルは決して使用されず、すべてのprocも使用されるわけではないことを確信しています。 最大の問題は、このDBで使用するために作成されたすべてのWindowsサービス、およびすべてのソフトウェアとデータベースのドキュメントが失われ、システム全体を設計した人物がどこにも見つからないことです。 関係を理解するのに役立つER図を作成できましたが、データベース管理の経験がないため、どこから始めるべきかわかりません。 また、この種の質問がここで質問されることを意図していない場合は申し訳ありません。

12 sql-server  documentation 

トランザクションを使用する必要があるパッケージで作業していますが、現在次のエラーが発生しています： SSIS package "CATS-Package.dtsx" starting. Information: 0x4004300A at Data Flow Task, SSIS.Pipeline: Validation phase is beginning. Information: 0x4001100A at CATS-Package: Starting distributed transaction for this container. Error: 0xC001401A at CATS-Package: The SSIS Runtime has failed to start the distributed transaction due to error 0x8004D01B "The Transaction Manager is not available.". …

12 sql-server  sql-server-2008-r2  ssis  ssis-2012  distributed-transactions 

SQL Server 2008R2には、非常に大規模な運用データベースと非常に大規模なテスト環境データベースがあります。両方のデータベースのテーブル構造は似ていますが、ユーザー/ログイン/権限/ロールが異なります。 テストデータベース内のいくつかのテーブルだけを月に1回程度、実稼働から定期的に更新する必要があります。 私がこれを行うことを計画している現在の方法は BCPユーティリティを使用して、本番から必要なテーブルのエクスポートを取得します。 bcpエクスポートファイルをテストサーバーにコピーします テストで更新しているすべてのテーブルのインデックスと制約を無効にします テストデータベーステーブルを切り捨てる BCPを使用して、テストデータベーステーブルにデータをロードし直します。 テストでインデックスを再構築し、制約を再度有効にします これはすべて、このような小さなタスクには少し複雑すぎるようです。また、多くのやり直しが生成されるようです（t-logで）これを行うより良い方法はありますか？ 私がこれを行う別の方法は、実稼働環境からテスト環境にバックアップを復元することですが、私が抱えている問題は、完全バックアップが非常に大きくなり、すべてのテーブルを更新する必要がなく、数回だけ更新する必要があることです- -また、運用データベースのユーザーとセキュリティはテストとは異なります。データベース全体を復元すると、運用データベースのセキュリティ設定によって上書きされます。

12 sql-server  sql-server-2008 

現在、環境内のSQL Server 2005/2008 / 2008R2 / 2012サーバーでのバックアップには標準のメンテナンスプランを使用しており、[バックアップの整合性の確認]ボックスは常にオンになっています。 バックアップの一部は非常に長時間実行されるため、このオプションをオフにすることをお勧めしますが、管理者はこの変更の影響とリスクを文書化する必要があります。 このオプションの使用と履歴を理解していますが、（私の意見では）発生する可能性のあるエラーが検証中ではなくバックアップステップ中に発生する場合、バックアップジョブの時間を2倍にする必要はありません。 私が間違っている？ストリーミングテープなどではなくディスクにバックアップする場合、これをオフにすることは最小限のリスクですか？（必要に応じて、ネットワーク経由でEMC DD-800バックアップアプライアンスにバックアップします。） これをオフにしても安全な場合の公式のMS推奨事項はありますか？ 環境内のすべてのバックアップで「検証」を実行していますか？それらをスポットチェックしますか？ 編集：明確にするために、メンテナンスプランで[バックアップの整合性の検証]をチェックすると、SQLは各バックアップの直後に各データベースで完全な復元を行います。これは、元のバックアップと同様にデータ/ IOを集中的に使用し、（基本的に）バックアップジョブの全体的な時間を2倍にします。これは、ありません（私の知る限り、ウィザードで行うことができない）、バックアップの「チェックサム」オプションを有効にすると同じ。

12 sql-server  backup 

複合WHERE句を含むクエリを作成する場合、たとえば： SELECT * FROM MyTable WHERE BitField = 1 AND VarcharField = 'asdf' また、そのbit比較を含めると、比較で除外されるのと同じフィールドが除外されるだけですvarcharが、そのbitフィールド比較が存在するとパフォーマンスが向上しますか？

12 sql-server  optimization 

新しいデータベースにデータをインポートしました（約600m行のタイムスタンプ、整数、倍精度）。次に、いくつかのインデックスを作成し、いくつかの列を変更しようとしました（スペース不足の問題がありました）。データベースはバキュームされます。 pgAdmin IIIは、「一時ファイルのサイズ」が50G〜+であることを教えてくれます。 これらの一時ファイルは何ですか？これらはSQL Serverトランザクションログのようなものですか？ どうすればそれらを取り除くことができますか、データベースは必要以上に大きいようです（データベースの合計サイズは91 GBです） Windows 2012サーバーでPosgres 9.4.1を使用します。 データベース統計タブのスクリーンショット：

12 postgresql  pgadmin 

この回答によれば、制限に使用される列にインデックスが構築されない限り、クエリはインデックスの恩恵を受けません。 私にはこの定義があります： CREATE TABLE [dbo].[JobItems] ( [ItemId] UNIQUEIDENTIFIER NOT NULL, [ItemState] INT NOT NULL, [ItemPriority] INT NOT NULL, [CreationTime] DATETIME NULL DEFAULT GETUTCDATE(), [LastAccessTime] DATETIME NULL DEFAULT GETUTCDATE(), -- other columns ); CREATE UNIQUE CLUSTERED INDEX [JobItemsIndex] ON [dbo].[JobItems]([ItemId] ASC); GO CREATE INDEX [GetItemToProcessIndex] ON [dbo].[JobItems]([ItemState], [ItemPriority], [CreationTime]) INCLUDE (LastAccessTime); …

12 sql-server  index  execution-plan  azure-sql-database 

バックグラウンド 私は、大規模なヘルスレコードDBについて多くの大きなレポートを作成し、一般的に管理しています（SP、機能、ジョブなどを作成します）。元のスキーマとそれを使用するソフトウェアは別のベンダーのものであるため、構造についてはあまり変更できません。ラボ、手順、ワクチンなど、追跡を必要とする多くのレコードがあり、それらは多数のテーブルに散らばっています。その多くは肥大化しており、インデックス付けが不十分です（これを多少修正できました）。 問題 問題は、DBをほとんど制御できないため、また特定の更新やパッチから変更される可能性があるため、これらのレポートの作成と保守が困難で面倒になることです（特に重複が多い場合）。必要なのは1つのパッチだけで、多数のレポートの大部分を書き直しています。さらに、結合、ネスト、選択、適用が積み重なると、クエリはすぐに難読化され、遅くなります。 私の「解決策」 私の計画は、これらすべてのレコードを1つの「キャッチオール」テーブルに書き込み、元のテーブルにトリガーを書き込んで、この集約テーブルのレコードを維持することでした。もちろん、更新後にトリガーが完全であることを確認する必要がありますが、保守性の観点から、データを参照するだけの方がはるかに簡単です。 テーブルは薄くて長く、必要なデータのみを保存します。次のようなものです。 CREATE TABLE dbo.HCM_Event_Log ( id INT IDENTITY, type_id INT NULL, orig_id VARCHAR(36) NULL, patient_id UNIQUEIDENTIFIER NOT NULL, visit_id UNIQUEIDENTIFIER NULL, lookup_id VARCHAR(50) NULL, status VARCHAR(15) NULL, ordered_datetime DATETIME NULL, completed_datetime DATETIME NULL, CONSTRAINT PK_HCM_Event_Log PRIMARY KEY CLUSTERED (id) ) 次に、type_idやアイテムのグループ化などのさまざまなリレーショナルテーブルを作成します。 これらのテーブルのいくつかはかなり書き込まれているので、私はこの考えを二番目に推測し始めています。私が書いているSPとレポートはデータも多く参照します。したがって、このテーブルが大量のI / Oを伴うレコードのロックとパフォーマンスの悪夢になることを心配しています。 …

12 sql-server  sql-server-2008-r2  trigger  ssrs 

たとえばD:\、SQL Serverをドライブのルートにインストールすると、サードパーティのソフトウェアからデータベースデプロイヤを実行するとエラーが発生します。 しかし、SQL ServerインスタンスをD:\SQL\（ドライブ内のフォルダーに移動する）に移動すると、インストールは完全に機能します。 私の質問は、データベースデプロイヤに関するものではありませんが、SQLがドライブのルートにインストールされることで問題が発生する理由に関するものです。これは悪い習慣ですか？ドライブのルートにSQL Serverをインストールしないのはなぜですか？

12 sql-server  installation 

私はdonorスキーマreferenceに従ってテーブルを作成しました： CREATE TABLE reference.donor ( donor_code smallint PRIMARY KEY, donor_name character varying NOT NULL, donor_type smallint REFERENCES reference.donor_type (type_id), alpha_2_code char(2) REFERENCES reference.iso_3166_1 (alpha_2_code) ); 私はテーブルを次のように設定しました： INSERT INTO reference.donor (donor_code, donor_name, donor_type, alpha_2_code) SELECT donor_code, donor_name, donor_type, alpha_2_code FROM reference.donor_template; 実行すると： \dt+ reference.* psqlの中に私はreference.donorテーブルを見ます： List of relations Schema | Name …

12 postgresql  schema  table  psql 

2つのテーブルがある場合： CREATE TABLE foo (ts timestamp, foo text); CREATE TABLE bar (ts timestamp, bar text); 私はのための戻り値というクエリを書きたいts、fooとbarその直近の値の統一見解を表しています。つまり、foo含まれている場合： ts | foo -------- 1 | A 7 | B そしてbar含まれています： ts | bar -------- 3 | C 5 | D 9 | E 私は返すクエリが必要です： ts | foo | bar -------------- 1 | A …

12 postgresql  join  window-functions 

24時間365日利用可能なデータベースを実行するために、SQL Server 2014 Enterpriseがインストールされています。私たちのデータベースは十分に大きい（200GB +）。また、新しいデータを読み取り、更新、または挿入するためにデータベースに毎分アクセスする多くのサービスがあります。クライアントに「ホット」再デプロイ機能を提供し、日々の更新（.netおよびスキーマの更新）をクライアントに対して透過的にしたいと考えています。アプリのバイナリを更新するロードバランサーを備えたクラスターに基づいたソリューションを見つけましたが、データベースの更新展開プロセスとこの問題を解決するためのベストプラクティスについては、まだいくつかの誤解があります。 スキーマの変更については、1つのサーバーを停止し、スキーマの変更を適用し、それを再起動してから、同じ変更を2番目のインスタンスに適用します。SQL Serverツールで実現できますか？これは一般的なアプローチですか？サーバーのバックアップ後のデータの同期方法 または、私は完全に間違った方向に考えていますか？より良い解決策はありますか？ 一般的なスキーマの変更：列の追加/削除、ストアドプロシージャの追加/削除

12 sql-server  sql-server-2014 

言語/データベース/システムに精通して、新しい機能/構成/クエリ/などをテストする必要がない時点がありますか。システムに実装する前に、特にデータを変更する機能に関して、封じ込め/シミュレートされたテストによって？または、テスト環境でシミュレーションによって新しいクエリをテストすることは常に不可欠ですか？ さらに指定するには、テストするのが常に最も安全であることは明らかです。ただし、リスクが非常に少ないためにテストに労力をかける価値がない場合を判断する方法はありますか？それを言い換える別の方法：機能を実装するために測定されたリスクを取ることはいつ、またはいつまで専門的に行われていますか？ また、すべてがバックアップされていると仮定しましょう。したがって、最悪の場合のシナリオでは、ある程度の労力でデータを復元できます。 誰かがこれに対処するために特定の専門家の経験を引用できますか？適切/可能な場合は参照を含めてください。

12 database-design  configuration  testing  learning  features 

エンタープライズDBを構築したSQLデータベースプロジェクトがあります。SSDTのスキーマ比較ツールを使用して、内部およびAWSがホストするSQLサーバーに数回デプロイしました。 SQL Ent 2012 sp2を実行しているAzure Hosted Win 2012 Serverに投稿するときの問題。「比較が完了しました。違いは検出されませんでした」と戻ってきます。 Enterprise Managerを開き、スキーマをSQLプロジェクトと比較して、違いがあることがわかるので、これが間違っていることはわかっています。 2014年のリリースでこのツールがどのように機能しなくなったかについて話している記事をいくつか見つけましたが、それらはバージョンの違いにあります。 [はい、Googleでこれを行いました。私がそうするのを忘れることで悪名高いので、述べます。] https://www.google.com/webhp?ie=utf-8&oe=utf-8#q=ssdt+data+compare+fail+to+detect+difference&start=10 私がチェックした他のことには、DBアカウントに無制限のアクセス権があることを確認することが含まれます。管理コンソールに接続できます。ローカルプログラムに接続できます。 問題があったことの最後の確認： 番号1の単一の戻り値を持つSPを作成しました。 テストのために何も返されない可能性があります。 SPを作成した後、すべてのインスタンスでスキーマ比較を実行しましたが、Azureサーバーを除くすべてのインスタンスで差異が示されました。 更新 これはサーバーで明示的に行われていることを確認しました。2台のコンピューター上の2人のユーザーがまったく同じ問題を抱えているからです。

12 sql-server  schema  ssdt