タグ付けされた質問 「best-practices」

SQL "sa"アカウントが使用されるべきでない方法で使用されていることを発見したため、すべてのSQLインスタンスでsaパスワードを変更しています。 （SQL 2005〜2017のサーバーは混合認証モードで実行されています。すべてのユーザーとアプリケーションは、ドメインアカウントまたは非sa SQLアカウントを使用して接続する必要があります。監視していますが、他のアプリ、ユーザー、または非-saアカウントを使用した内部spid。） いくつかの質問： Q1：saパスワードを変更するには、SQLの再起動が必要ですか？ saアカウントのパスワードを変更した後、SQLサービスの再起動が必要であると言ういくつかの参照を見つけました。 DBA SE：saパスワードの変更 SQLAuthority：Management Studioを使用したSAログインのパスワードの変更 本当？または、認証モードを変更する場合にのみ？または、私が日常的にsaとしてログオンする場合のみ？ このSQL Server Centralスレッドは、変更すると既存のSQLエージェントジョブなどに影響を与える可能性があることを示唆しています。それは心配ですか？または、誰かがSAアカウントをSSISパッケージなどにハードコーディングした場合にのみ？ （重要な場合は、SQLサービスとSQLエージェントサービスにドメインアカウントを使用し、SSISパッケージまたはPowerShellスクリプトを呼び出すジョブにドメインプロキシアカウントを使用します。） Q2：saパスワードを「通常の」方法で変更できますか？ 他のアカウントと同じようにリセットできますか？SSMSを使用するか、より可能性が高い： ALTER LOGIN sa WITH PASSWORD = 'newpass'; または、シングルユーザーモードまたは計画的なダウンタイムを必要とするモードに入る必要がありますか？（「sa」として接続しているときではなく、ドメインアカウントから実行していることに注意してください。） Q3：このパスワードのローテーションを定期的に実行する必要がありますか？または、問題が見つかった場合のみ？ これは推奨される「ベストプラクティス」ですか？

13 sql-server  security  best-practices 

私は最近、サーバーの一人のユーザーとの定期的なアクセス権を共有したいと思ったし、私は簡単なことを実現CREATE USERし、GRANT ALL ON DATABASEコマンドは彼が単純で実行できなかったSELECTデータのを。 特定のデータベースのすべてのテーブルへの権限を特定のユーザーに付与しpublicたいのですが、何らかの特権を許可するかどうかわからないため、スキーマ全体へのアクセスを許可するのが最善のアイデアかどうかわかりませんエスカレーション。他の方法はありますか？

13 postgresql  best-practices  permissions  access-control 

このドキュメントで説明されているベストプラクティスについて質問したいと思います。 http://info.mongodb.com/rs/mongodb/images/MongoDB-Performance-Best-Practices.pdf 複数のクエリルーターを使用します。複数のサーバーにまたがる複数のmongosプロセスを使用します。一般的な展開は、アプリケーションサーバー上のmongosプロセスを同じ場所に配置することです。これにより、アプリケーションとmongosプロセス間のローカル通信が可能になります。mongosプロセスの適切な数は、アプリケーションと展開の性質によって異なります。 展開についてのほんの少しの背景。多くのアプリケーションサーバーノードがあります。それらはそれぞれ、ステートレスRESTful WSで1つのJVMベースのプロセスを実行します。このベストプラクティスが示唆するように、すべての単一のアプリケーションサーバーノードは独自のmongosプロセスを実行します。つまり、JVMプロセスの数は常にプロセスの数に等しくなりmongosます。 すべてのmongosプロセスは、3つの構成サーバーと複数のmongo断片（各断片内にレプリカセットがある）に接続します。シャード展開を使用している場合でも、実際にはコレクションをシャーディングしていません。実際、作成時にすべてのシャードに分散する多数のデータベースがあります（これが現時点でのシャーディングの主な使用例です）。 ベストプラクティスでは「適切なmongosプロセスの数はアプリケーションとデプロイメントの性質に依存する」ことも示唆しているので、私たちの使用mongosが実際に適切かどうか、または複数の専用mongosノードを用意して、アプリサーバーはmongosローカルで実行せずに接続します。 mongosアプリケーションサーバーのインスタンス数またはMongoDBクラスターのサイズに関連して適切なインスタンスの数を決定するための最適なアプローチについて、あなたはどう思いますか？ 最近、ステートレスWebサービスのクラスター管理を検討し始めました。つまり、Docker、Apache Mesos、Kubernetesなどのツールを意味します。Dockerを使用している場合、一般的にコンテナ内で複数のプロセスを実行することは推奨されません。この事実を考慮すると、アプリケーションサーバーコンテナとmongosコンテナを常に同じ物理ノードに配置し、同じ量のプロセスを確保することは非常に困難になります。これは、このベストプラクティスが今説明したクラスターアーキテクチャにまだ当てはまるのかと思います。そうでない場合は、mongosこのアーキテクチャでプロセスを見つけて展開するためのより良い方法を提案してください。

12 mongodb  best-practices  sharding  deployment  docker 

私はいつも列エイリアスを次のように見て、書いてきました SELECT 1 as ColumnName しかし、今日使用したクエリに出くわしました SELECT ColumnName = 1 これら2つのクエリの実行方法に違いはありますか？または、どちらを使用するかについて、DBA間に標準はありますか？ 個人的に私は、第二は、読み取り/（良い例を長い列定義に維持することが容易になるだろうと思いますここからこの記事私はすべきではない、いくつかの理由がある場合）、しかし、私は今日はとても疑問に思って前に使用第二構文を見たことがありませんそれを使用します。

12 sql-server  t-sql  best-practices 

SELECT複数の列が同じCASE WHEN条件を使用して、条件が1回だけチェックされるように句を書き換える「より良い」方法はありますか？ 以下の例を参照してください。 SELECT CASE testStatus WHEN 'A' THEN 'Authorized' WHEN 'C' THEN 'Completed' WHEN 'P' THEN 'In Progress' WHEN 'X' THEN 'Cancelled' END AS Status, CASE testStatus WHEN 'A' THEN authTime WHEN 'C' THEN cmplTime WHEN 'P' THEN strtTime WHEN 'X' THEN cancTime END AS lastEventTime, CASE testStatus WHEN …

12 oracle  database-design  oracle-10g  best-practices 

さまざまな国でSQL Serverをセットアップしようとしています。リンクする必要がありますが、直接リンクする必要はありません（リンクサーバーのように）。言い換えれば、それらは疎結合できます。 それらをVPN経由で接続してリンクサーバーとして使用するか、Webサービス経由で疎結合を使用する方が良いでしょうか？ 「より良い」とは、安定性を指します。

12 sql-server-2008  best-practices  network 

ストレージとパフォーマンスの両方の観点から、varchar列の大きさを決定する最良の方法を理解しようとしています。 パフォーマンス 私の研究から、それはそうですvarchar（max）は、本当に必要な場合にのみ使用してください。つまり、列が8000文字以上を収容する必要がある場合、1つの理由はインデックス作成の欠如です（ただし、一般にvarcharフィールドでのインデックス作成には少し疑いがあります。ただし、DBの原則はかなり新しいので、それが根拠がないかもしれません。 ）および圧縮（より多くのストレージの問題）。実際、クエリは可能な最大サイズを考慮しなければならないため、一般的に人々はvarchar（n）.... oversizingを行うときに必要なものだけを使用することを推奨しているようです。しかし、エンジンはデータの実際の平均サイズの推定値として、示されたサイズの半分を使用することも述べられています。これは、データから平均サイズを決定し、それを2倍にし、それをnとして使用する必要があることを意味します。ただし、変動性が非常に低いがゼロではないデータの場合、これは、最大サイズの最大2倍のサイズ変更を意味します。洞察をいただければ幸いです。 ストレージ 実際のストレージは実際のデータに制限されていることを念頭に置いて、行内ストレージと行外ストレージのしくみについて読んだ後、nの選択はストレージにほとんどまたはまったく影響がないように思えます（それがすべてを保持するのに十分な大きさであることを確認してください）。varchar（max）を使用しても、ストレージに影響はありません。代わりに、可能であれば、各データ行の実際のサイズを〜8000バイトに制限することが目標になる場合があります。それは物事を正確に読んでいますか？ コンテキスト 一部の顧客データは少し変動するため、通常、必要な列よりも少し幅を広く（たとえば15〜20％大きく）します。他に特別な考慮事項があるかどうか疑問に思っていました。たとえば、一緒に仕事をしている人から、2 ^ n-1サイズを使用するように言われました（ただし、それを証明するものは見つかりませんでした。 最初のテーブル作成について話している。新しいテーブルの送信を開始し、サンプルデータ（または最初の本番データセットのみ）を送信することをお客様から言われます。これを見て、データを保持するためのテーブルを作成します。将来のインポートとサンプルの内容を処理できるように、テーブルを作成します。ただし、特定の行は長くなるようにバインドされているため、それらをパディングします。 問題はどれくらいか、そして技術的なガイドラインはありますか？

12 sql-server  performance  best-practices  storage  varchar 

SQL Serverのいくつかのバージョンをテストに使用し、ラップトップにインストールしています（2012、2014、2016、2017）。先日、更新（SP、CU）間で以前のバージョンのファイルを含むフォルダーがあることに気付きました。すべてのバージョンで、実際にはかなりのスペースが使用されています。 （C：\ Program Files（x86）\ Microsoft SQL Server \にあります） 110\Setup Bootstrap\Log - 91.8 MB (818 files) 110\Setup Bootstrap\Update Cache - 608 MB (2,382 files) （以下のフォルダはすべてC：\ Program Files \ Microsoft SQL Server \にあります） 110\Setup Bootstrap\Log - 1.18 GB (3,715 files) 110\Setup Bootstrap\Update Cache - 9.58 GB (14,766 files) 120\Setup Bootstrap\Log - …

11 sql-server  best-practices  disk-space  management 

私にこの質問をするように促す2つの理由があります。 tSQLt T-SQLテストフレームワークtSQLtは、デフォルト以外の照合を持つ列が存在する場合、それを「高重大度」の問題と見なします。テストの作成者は次のように述べています。 すべての文字列列に、データベースのデフォルトの照合と一致する照合が必要であることを示唆していません。代わりに、それが異なる場合には、それには十分な理由があるはずだと提案しています。 しかし、前述のように、失敗したテストの重大度は高いと見なされます。 Octopus Deploy Octopus Deploy Serverの構成中に、OctopusServer-instanceの初期化中に、セットアップがFATALエラーで失敗します。記事これは単純な要件ですが、理由を説明しないエラーメッセージに関連するが、それはからとタコのバージョン3.8を含め、今後の展開のための要件となることを述べています。 補足として、RedGateのCIツールパッケージであるDLM Automation Suiteは、さまざまな照合を使用したデプロイメントを問題なくサポートします。 すべての列の照合順序をデータベースのデフォルトに保つという推奨は、私にとってはガイドラインまたはベストプラクティスに似ています。一部の人がなぜこのような重大なエラーと見なしているのですか？

11 sql-server  best-practices  collation 

1つのIBM 3400サーバーを最初から再構築します。このサーバーは、Windows 2008 R2で実行されているSQL Server 2008インスタンス専用です。 新しいRAID構成を作成します。マシン内部に6つのSCSI 73 GBドライブとIBM ServerRAID 8Kコントローラーがあります。RAIDレベルを設定する良い方法は何でしょうか？コントローラーに2つ、3つ、または1つのフィールドを配置する必要がありますか？ 次のいずれかの解決策を検討しています。 すべてのディスクを使用して、RAID 10プールを作成します。 RAID 1eプールに4つのディスクを使用し、それを使用してデータベースデータとOSを格納し、他の2つのディスクをRAID 0プールに使用して、それを使用してデータベースログを格納します。 他のいくつかの組み合わせ。 ストライプユニットサイズが大きいほど良いですか？ このサーバーは、複製されたデータベースのサブスクライバーになります。その主なタスクは、レプリケーションエージェントのみが書き込みを行う、レポートとデータの取得です。データベースのサイズは約90 GBです。

11 sql-server  performance  best-practices  disk-structures 

ストアドプロシージャを十分に堅牢にし、非常に適切にスケーリングし、エラー処理を含めるための良い方法は何ですか？ さらに、ストアドプロシージャで複数のエラーシナリオを処理し、呼び出し元のアプリに意味のあるエラー情報を返すインテリジェントなフィードバックシステムを使用するための最良の方法は何ですか？

11 sql-server-2005  stored-procedures  best-practices 

このクエリに基づいて、総読み取り数が少ない（1または2のように0または0に非常に近い）と、大量または中程度のユーザー更新（このクエリで挿入または削除が見つからなかった）が行数が多い場合、理論的にはインデックスを削除する必要があります。 SELECT DISTINCT OBJECT_NAME(s.[object_id]) AS ObjectName , p.rows TableRows , i.name AS [INDEX NAME] , (user_seeks + user_scans + user_lookups) AS TotalReads , user_updates UserUpdates FROM sys.dm_db_index_usage_stats s INNER JOIN sys.indexes i ON i.[object_id] = s.[object_id] AND i.index_id = s.index_id INNER JOIN sys.partitions p ON p.object_id = i.object_id WHERE OBJECTPROPERTY(s.[object_id],'IsUserTable') …

11 sql-server  index  index-tuning  best-practices 

pg_catalogスキーマ内のオブジェクトは暗黙的にsearch_path（docs）にあるので、そのスキーマに拡張機能をインストールすることをお勧めしますか？

11 postgresql  postgresql-9.4  best-practices  postgresql-extensions 

誰かがCustomerLocationテーブルに対するこのユーザーの回答を理解するのを手伝ってくれませんか。注文テーブルに住所を保存するための優れた方法が本当に必要です。 私が探しているのは、住所を設定する方法です。そのため、住所を編集しても、顧客が住所を更新したり移転したりしても、注文は影響を受けません。 現状では、私のスキーマは次のようになります。 Person |EntityID| EntityAddress |EntityID|AddressID| Address |AddressID|AddressType|AddressLine1|AddressLine2| Order |OrderID|BillingAddressID|

10 database-design  best-practices 

私は自分のリーグではないデータベース設計の問題に出くわしました。そして、私の頼りになるDBAの第一人者が消防訓練に出かけています。 本質的に、私は次の主キー（簡潔にするためにPK）を持つテーブルを持っています。 child_id integer parent_id integer date datetime child_idそして、parent_idエンティティテーブルへの外部キーです。「子」テーブル自体にも「親」テーブルへの外部キーが含まれています。loはそれぞれ、child_id常にparent_id上記のテーブルで想定されているものと同じものを参照します。実際、この2つを同期させるための追加のコードがあることがわかります。 これにより、この熱狂的な正規化の初心者は「代わりに冗長性を削除する必要があります！」と言います。 私は次のように分解します。 Table_1 PK: child_id integer date datetime Table_2 PK: parent_id integer date datetime Table_3: (already exists) child_id integer PRIMARY KEY parent_id integer FOREIGN KEY そして、これらの人たちを自然な方法で結合すると、元のテーブルが回復します。この5NFを作ったのは私の理解です。 しかし、今ではビジネスルールが隠されていることに気づきました。 通常、特定child_idのに関連付けられている日付は、対応するに関連付けられている日付のサブセットである必要がありますparent_id。最初のテーブルがこのルールを適用していることがわかります。 日付が大きくなりすぎるまで自由に表1に追加できるため、私の分解ではルールを適用しません。 これは私をここに導き、次の質問があります： この分解は5NFですか？私はそれが挿入異常を許可すると言うだろうが、また次のそれ自体、Wikiの例に従うように見えるこのガイドを。「私が強調したもの」というフレーズは、「3つの別個のレコードタイプからなる正規化された形式からすべての真の事実を再構築できる」という特別な休止を与えますTable_1。 この分解が気に入らないとしましょう（気に入らない）。テーブルとコードをそのままにしておくことが実際的な解決策であることを私は自由に認めます。しかし、理論的には、最初のテーブルから離れてビジネスルールを保持するように制約を分解または追加する方法はありますか？

10 database-design  schema  normalization  relational-theory  best-practices