SQL Server 2005のtempdbファイルが無効な（SSD）ドライブに移動されました。ドライブを検証する方法、またはファイルを元に戻す方法は？
SQL 2005 32ビット開発者版、最近のすべてのサービスパック
Windows Server 2003 Standard 64x、最近のすべての更新
Fusion IOドライブ
開発サーバーに新しい80GBSSDカードをインストールし、tempdb（開始サイズ10GB）でALTER TABLEを実行してそれらのファイルを新しいドライブに移動し、SQL Serverを停止してから再起動を試みましたが、SQLは実行されません。 「サービス固有のエラーが発生しました：1814」で開始します。 Sys.Messagesの1814には、「tempdbを作成できませんでした。使用可能なディスク容量が不足している可能性があります。tempdbドライブ上の他のファイルを削除して追加のディスク容量を解放し、SQLServerを再起動してください。イベントログで追加のエラーを確認してください。 tempdbファイルを初期化できなかった理由。」アプリケーションイベントログに「ファイル 'F：\ TempDB'の作成またはオープン中にFCB :: Open：オペレーティングシステムエラー5（アクセスが拒否されました。）が発生しました。オペレーティングシステムエラーを診断して修正し、操作を再試行してください。」 SQLサービスはドメインアカウントとして実行するように構成されており、そのアカウントはボックスのローカル管理者です。
私の推測では、SQLServerで使用するために新しいドライブを「有効にする」場所にステルスビットを構成する必要があります。これが何であるかについて何か考えはありますか？
私が本当にやりたいのは、そのドライブにtempdbファイルをビルドしないようにSQLに指示することです...しかし、これを行うには、ファイルを移動するためにALTER DATABASEを発行する必要がありますが、それを発行するサービスを開始することはできませんコマンド。インスタンスを実際に実行せずに、SQL Server 2005（名前付き）インスタンスのtempdbファイルを移動するにはどうすればよいですか？ （これはSQL 2005なので、2000または7.0のようにマスターデータベースのテーブルをハックすることはできません。）
いいえ、システムデータベースのバックアップはありません。それとも、それはここで役に立ちましたか？
読んだ。エラーメッセージ。
それは言う：
アプリケーションイベントログに、ファイル「F：\ TempDB」の作成中またはオープン中に、「FCB :: Open：オペレーティングシステムエラー5（アクセスが拒否されました。）」が発生しました。
「アクセスが拒否されました」と誰かに説明してもらうことをお勧めします;）
私の推測では、SQLServerで使用するために新しいドライブを「有効にする」場所にステルスビットを構成する必要があります。これが何であるかについて何か考えはありますか？
ええ、それらはセキュリティと呼ばれています。 NTFSは、ドライブにかなり詳細なセキュリティを備えています。 SQL Serverを実行しているユーザー（インストール方法によって異なります）は、ファイルを作成するためにドライブに必要なアクセス許可を失っています。 SQL Serverについて「特別な」ことは何もありません。これは、単純で原始的な通常のファイルシステムのアクセス許可に関する問題です。
SQLサービスはドメインアカウントとして実行するように構成されており、そのアカウントはボックスのローカル管理者です
まあ、ローカル管理者であることに加えて（無関係、強くアドバイスされていない-真剣に強く）-このアカウントが実際に問題のファイル（または同様の名前のファイル）を作成できるかどうかを確認してください。そうでない場合（ファイルシステムのアクセス許可）、それが問題です。私の賭け。
そうは言っても、一般的に、tempdbファイルにSSDを使用することについて質問します。 99％のケースで真剣にお金を浪費しています。
管理者（私ではなく、正直なところです！）がファイルに間違ったパスを入力したときに問題が発生したようですが、確実なことはわかりません。彼は、SQLを-cおよび-fスイッチで起動し、ファイルを適切な場所に再変更することで、なんとか修正できました。
（お時間を割いて申し訳ありません。このあたりの同じソースからの問題がまれにしか発生しない場合は繰り返し発生します。基本的な問題は一部の人々にとって基本的ではないことに気付いたと思います。）
システムデータベースをホースで接続したように聞こえます。常にバックアップシステムデータベース......これらは後でこのようなときに便利になります。
http://support.Microsoft.com/kb/943635
sQLを再度実行するためにそれを試してください-次に、dbでアタッチを実行します。
そしてもちろん、OSが新しいドライブを認識し、すべてがフォーマットされて準備ができていることを確認します。また、SQLを実行しているIDがそのドライブにアクセスできることを確認します。
それがお役に立てば幸いです。
システムデータベースのバックアップに関して：マスター、モデル、msdbはい。 Tempdbは、データベースエンジンサービスが再起動されるたびに再構築されるため、tempdbをスキップします。
これは、ALTER DATABASEを使用してtempdbを移動すると、SQLサーバーが新しいSSDドライブではなく元のドライブで指定された空き領域（この場合は10GB）を探すという既知のバグに関連している可能性があります（大きな可能性があります=）。したがって、元のドライブに10GBがない場合、失敗します。最初にデータベースを小さいサイズ（1MBなど）を使用して新しいSSDドライブに移動してから、必要なサイズ（10GB）に再度サイズ変更する必要があります。
ブレントオザールはそれを説明しました ここ より良い。
すでにこれを解決したかどうかはわかりませんが、ここに進みます... SQLが再起動時にデータファイルを作成するためにフォルダ「F：\ TempDB」を検索しているようです。 F：\は新しいFusion-IOドライブを駆動しますか？はいの場合、SQLがアクセスできるようにするための適切な権限を持つフォルダ「TEMPDB」をドライブにすでに作成していますか？
SQLはフォルダに直接アクセスしようとし、フォルダが存在しない場合は作成しません...おそらくそこに問題があります！お役に立てれば。
よろしくChirag