SqlServer OLTPスペシャリストの採用、どのような経験や要件を探すべきですか？ [閉まっている]

Question

現在作業中のOTLPプロジェクトでDbのパフォーマンスの問題が発生しています。別の開発者と私は、蓄積されたパフォーマンスの知識の終わりに到達し、アプリケーションを高速化するためにチームに参加する個人を探しています。

一部の背景については、スキーマを変更してデータの一部を非正規化し、すべてのクエリを最適化し、複数のデータベースチューニングアドバイザーを実行してインデックスを適切に取得し、MSSqlのサーバーオプションを調整しました。

参加する必要はなく、参加が遅くなり、デッドロックとは何かを伝えるために、上記のすべてのステップを使い果たした後に何をすべきかを知っている人が必要です。

共有するOLTP DBAを雇うヒントや経験はありますか？面接プロセス中にDBAにどのような質問をすることができますか？

これは奇妙な状況です。現在のチームよりも詳しいことを知っている人が必要なのはわかっていますが、次のステップがわからないため、どの質問をするべきかわかりません。それは理にかなっていますか？

Answer 1

OK、これは何かを教えてくれます：

  

一部の背景については、スキーマを変更してデータの一部を非正規化し、すべてのクエリを最適化し、複数のデータベースチューニングアドバイザーを実行してインデックスを適切に取得し、MSSqlのサーバーオプションを調整しました。

すでに、DBAと呼ばれる人々の90％ができることと一致するか、それを超えています。

問題は、DBAの多くは実際にはプログラマーではなく、システム管理側にいるということです。 TSQLが得意なだけでなく、他のプログラミング言語も知っているDBAプログラマが必要です。

私はこのようなデータベースのチューニングの問題にかなりの時間を費やしており、多くの場合、ソリューションにはフロントエンドからデータベーススキーマまでの大幅な再設計が含まれます。これらの問題を単独で解決することはできません。また、アーキテクチャ全体を完全に制御（および完全に理解）しなければ、必要なパフォーマンスを得ることができません。

あなたは仕事に最適な人かもしれません。OLTPのパフォーマンスの問題に集中できるように、忙しい仕事を外して誰かを雇う方が賢明かもしれません。

Answer 2

ここでは慎重に変更する必要があります。GuruDBAを雇って、データベースのパフォーマンスを大幅に向上させても、そのアーキテクチャに根ざしたアプリケーションに問題がある場合があります。

いくつかのアイデア：

1. 最適化した最も複雑なクエリをQAの候補DBAに渡し、再度最適化するよう依頼します。彼らに何をしたのか、どのようにしたのかを説明してもらいます。

2. 複数のファイルグループ、RAIDアレイ、データパーティション、64ビットと32ビットのパフォーマンスなどを使用する場合は、この人がハードウェアを理解していることを確認してください。

3. ソフトウェアアーキテクチャのバックグラウンドも持っている人を探してください。

4. SQLサーバーに関するいくつかの難しい質問をします。 OVERステートメントとは何ですか？ GUIDは良いプライマリキーですか？また、なぜ、int IDが望ましいですか？

Answer 3

最適化の前にDBのチューニングを少し戻し、それを提供します。あなたが行った変更と比較して、パフォーマンスが同じかそれ以上になるように調整できるかどうかを確認します。

なぜ彼らがそのテクニックを選んだのか尋ねてください。

参照を取得し、参照元と一致する可能性が最も高い参照元の環境について調べます。

Answer 4

優れたDBAは、インタビューの中で、次にどのステップを踏むかを高いレベルで伝えることができます。ここでは、問題の解決策よりも、思考プロセスにもっと注意を払う必要があります。 DBAがいくつかの解決策を提供したら、戻ってそれらをクイズし、なぜそれらの方法で問題を解決する必要があるかを尋ねます。

この方法は、男性と男性を非常に迅速に区別します。

Answer 5

dbの最大パフォーマンスにどれくらい近いですか？このテクノロジーでは解決できないOLTP問題を作成するのは非常に簡単です。エリックが言ったように、全体的なアーキテクチャの再設計が適切かもしれません。ラムを追加し、ラムを追加します：）

Answer 6

確かに、データベースを見ることなく、最適化の最良の方法が何であるかを言うのは難しいです。行ったことを考えると、おそらくデータベースデザイナーを雇う必要があります。データベースデザイナーは、現在のサイズ範囲でデータベースを設計および調整した経験があります。どのように問題にアプローチするかを尋ねる際に、インタビュアーがパフォーマンスの低いクエリを最初に調べ、プロファイラーを実行して何が起こっているのかを確認し、それらを識別するかどうかを確認します。ユーザーは、パラメータスニッフィングとその回避方法に関する特定の質問に答えることができるはずです。カーソルを回避するために使用できる方法は何か、統計を更新する必要があるのはなぜか、クエリをsaregableにする理由は何ですか。パフォーマンスチューニングで検討する一般的なものがいくつかあります。ネットワークは最大限に活用されていますか（データベースではない場合もあります）、全体的な設計が十分に考慮されていませんか？一般的にパフォーマンスが悪いSQlコードを使用していますか？たとえば、すべての検索で最初の文字としてワイルドカードが許可されている場合、ワイルドカードを高速にすることさえできません。結合が複数列の自然キー上にある場合、本来よりも遅くなります。フィールドに複数の情報を保存して、データを取り戻すための多くの操作を引き起こしていますか？カーソルを使用していますか？関数を使用していますか？すべきではないときにコードを再利用していますか？必要最小限の情報を常に返していますか？接続を閉じていますか？デッドロックが発生していますか？テーブルの行が広すぎませんか？特定のテーブルにあまりにも多くのレコードがありますか（古いレコードをパージするか、アーカイブデータベースに置くと大きな違いが生じます）？コードのどのくらいが行指向であり、セット指向ではありませんか？これらは、経験豊富なデータベース担当者が見るであろう種類の例であり、したがってインタビューで話すべき種類の例です。

いくつかの不適切なコード例（既に最適化されているものを知っている）は、それらがどのように調整されるかについてのアプローチについて良いアイデアを与えることができます。整然としていて、SQLの知識が豊富な人が必要です。

パフォーマンスチューニングに関する優れた書籍がいくつかあります。インタビューする前に、それらを入手して使い慣れることをお勧めします。