偶発的なDBAのリソース[終了]

Microsoftプラットフォーム内では、ほとんどのエンタープライズレベルのプログラム（SharePoint、System Centerアプリ、Dyamicsアプリなど）はすべてSQL Server上で実行されます。これらのプログラムの管理者にとって、SQL Serverは多くの場合、主な焦点となるプログラムの前提条件としてインストールされるブラックボックスです。その結果、インストールのSQL側に行われる計画が（あるとしても）非常に少なく、さらに上流のどこかで表面化する問題につながります。

• ドライブを満たすトランザクションログ
• メンテナンスプランなし（またはインデックスの再編成と再構築の両方を行うプランなど、情報に基づいていないプラン）
• 管理されていない自動成長
• 同じスピンドル上のデータベースとログ
• 不適切に選択されたRAIDレベル
• バックアップなし（または復旧計画）

それで...「偶発的なDBA」はどのような種類の問題に遭遇する傾向があり、偶発的なDBAがSQL計画、管理、およびパフォーマンスチューニングの基本を理解するのに最も役立つリソースはどれですか。

TechNet Magazine向けに執筆している一連の記事とQ＆Aコラムをご覧ください。これらは主に、偶発的（「不随意」）DBAを念頭に置いて書かれています。

効果的なデータベースメンテナンスのヒントは、特にDBメンテナンスの問題を理解するための不本意なDBAの入門書として書かれました。

SQL Serverのログと回復について

一般的なSQL Serverセキュリティの問題と解決策

SQL Serverバックアップについて -3部構成シリーズの第1部。パート2は復元の使用（09年9月号）、パート3はバックアップなしの復元（09年11月号）

また、私のブログと妻のブログもチェックアウトする必要があります（広告や情報だけではありません）-私たちは両方とも、さまざまな技術レベルで膨大な量のブログを書いています。

よく見る一連の投稿の1つは、毎週のアンケートの結果の社説です。これらは通常、不本意なDBAに役立つ広範なトピックに関連しています。編集投稿は「重要」または「重要」で始まります。実際、今週の調査は、非自発的なDBAであることに焦点を当てています-非常にタイムリーです！

非自発的なDBAのことをよく理解しています-実際、キンバリーと私はSharePointのMicrosoft Certified Mastersクラスを数日間教えているので、SharePoint管理者はSQL Serverで何をすべきかを知っています（SQLの1週間も教えています） 。

これがあなたの役に立つことを願っています。

ショーン、あなたがどこから来たのか理解しています。

他の多くの人もそうであるように、私たちはここで同様の船に乗っています。今日の経済に耐えられない。

経営陣（上級経営陣を含む）に繰り返し苦情がありますが、私たちの状況はこれです。自任の「DBA」（別のフロアにある別の「開発チーム」）は、残念ながら2つのO'Reillyの本とKBのプリントダンプを使用しているジュニア以下の人物を知っています。彼女は仕事をしていて、蜂蜜を人の耳に注ぐのが得意であり、人はまた、蜂蜜を最大のムッキー・マックの耳に注いでいます。

確かに、DBAの「取引」を学ぶことができるのが理想ですが、繰り返しますが。:)

私は、個人的に次の問題に遭遇しました（squillmanのかなり鈍いものをエコーするためですが、完全に間違っているわけではありません）。

• トランログ。あなたが正しい。これらは一体何なのでしょうか？したがって、データベースとサーバーを復元する必要がありましたが、「tran logの再生」とは正確に何を意味するのでしょうか？:)
• ちょっと待って、これらのデータベースが大きくなったとはどういうことですか？それらをどのように縮小しますか？または、少なくとも成長を維持しますか？
• 異なるサーバー間でのインストールの標準化（この画像は「dev」用、この画像は「prod」用、この小さな画像は市場からずっと帰ってきた:)
• メンテナンススクリプトと、長期間にわたるデータベースの管理を支援する方法（観葉植物を栽培し、それらが葛にならないようにすることのようなものです。）
• 常に確認して、プロギーはC：\に行き、ロギングおよび/またはデータベースはD：\に行きます。これは標準化を定式化したものです（C：\は2つのミラーディスク、D：\は通常RAID5です）
• バックアップ用に個別のSQLライセンスとクライアントを購入する必要があります。
• 開発チームがSQLデータベース自体に割り当てるユーザーの管理、DBOロールの管理などを確認してください。データベース内のユーザー権限に関して、適切なセキュリティモデルを確保してください。
• SQLサービスが操作できるドメインサービスアカウントの調査。サービスアカウントに必要な権利（ある場合）。

（投稿でかなり良いものを見つけました。）

他の人と同じようにハンディキャップで作業しているため、可能であれば、SQLの知識をチーム全体に広めるようにしてください。知っていることを共有し、他の人にも同じことを教えます。フレンドリーに。SQLの帽子をかぶるのは大変な苦痛ですが、少なくとも多くの目と思考のプロセスは1つのプロセスよりも優れています。

ただし、何よりも、悪魔のようにDBAスタッフを取得してください。:)

私は仕事に約1年、DBAの役職に就きました。これは約5か月前でした。それ以来、私は500,000フィートのビューから（時には500フィートでハードデッキにぶつかる）250,000ビューから 500フィートのビューまで、さまざまなブログを読んでい ます。また、SQLServerPediaはあなたの友人です。彼らは偶然のDBAのためにたくさんの良いものを持っています。

私は私を不安にさせた状況に投げ込まれました。たとえば、この仕事を「与えられて」からバックアップを行っているので、実稼働データの最初の復元のためにフル、差分、およびTログが手元にあり、他の人はパニックに見えなかったので、表示できなかった気分が悪い。私はDBAの帽子をかぶると船外に出ますが、フルタイムの仕事（ネットワーク管理者）ではないので、「ごめんなさい」よりも安全である必要があります。

効果的なデータベースメンテナンスのヒント

戦術的な努力から始めてください。データベースがクラッシュしたり、正常に動作しない場合は、それらの問題の解決に焦点を合わせます。

次に、より戦略的な項目から始めます：バックアップと復元。データベースの内外を復元する方法を理解し、運用停止中のコストのかかる間違いを防ぐための詳細な手順を作成します。

大きな変更やバックアップ/復元などをテストするためのハードウェアがない場合は、その方法を見つけてください。

ジュニアDBAを雇うと、彼女にMicrosoft®SQL Server（TM）2005 Administrator's Companionを購入しました。それは私が始めたときに持っていたと思う本です。