none
SQL Server 2008 R2 が Dドライブにセットアップ出来ない

    質問

  • SQL Server 2008 R2(x64)  (ExpressEdition with Advanced Service)を、あえてDドライブにインストールしようとしています。 

    しかしインストーラの途中の「機能の選択」のところで、共有機能ディレクトリがグレーアウトしていて選択出来ない場合が有ります。

    x86の共有ディレクトリは変更できるのですが、x64の共有ディレクトリが選択出来ない場合が有り困っています。

    インストール先のマシンは2008ServerR2(x64)です。メーカや機種の差異によっても出来たり出来なかったりするようです。

    インストール時にコマンドプロンプトからセットアップを引数付きで強制的にDドライブにインストールするように指定しても、

    OSQLやBCPなどのツールがCドライブにインストールされてしまいました。

     

     なぜDドライブにインストールするように指定出来ない場合があるのか?又、Dドライブにインストールするように指定するには

    どうしたら良いか、教えて下さい。

     

    2011年7月22日 6:01

回答

  • 公式な情報は見当たりませんが、

    Visual Studio や .NET Framework をはじめとした SQLServer Components が含まれているものを1つでもインストールしていると、共有ディレクトリが確定済みとみなされてしまい、変更できないらしいです。(そのフォルダが存在しているかどうか、そこにファイルがあるかどうかは関係ないようです)

    google で検索すると、

    http://it.toolbox.com/blogs/programming-life/sql-server-2008-install-changing-install-path-when-its-defaulted-and-read-only-28355

    というのが見つかりました。SQL Server をインストールする際に、途中でセットアップ設定ファイルをカスタマイズすることで、共有ファイルのインストール先を書き換えてからセットアップを実行すればよいようです。ただし、この方法はサポート対象外になるかもしれません。個人的には、セットアップ設定ファイルは同じ構成で再セットアップするために保存しておくものであって、カスタマイズをすることが前提なものではないのではないか?と思いますので、Microsoft のサポートにきちんと相談したほうがよいのではないかと思います。

    (項目としては、セットアップ時に変更可能である項目を書き換えているだけですので、SQL Server Components が何も入っていない状態であれば、SQL Server の動作に影響を与えることはないと思います)

    2011年7月22日 7:52

すべての返信

  • 公式な情報は見当たりませんが、

    Visual Studio や .NET Framework をはじめとした SQLServer Components が含まれているものを1つでもインストールしていると、共有ディレクトリが確定済みとみなされてしまい、変更できないらしいです。(そのフォルダが存在しているかどうか、そこにファイルがあるかどうかは関係ないようです)

    google で検索すると、

    http://it.toolbox.com/blogs/programming-life/sql-server-2008-install-changing-install-path-when-its-defaulted-and-read-only-28355

    というのが見つかりました。SQL Server をインストールする際に、途中でセットアップ設定ファイルをカスタマイズすることで、共有ファイルのインストール先を書き換えてからセットアップを実行すればよいようです。ただし、この方法はサポート対象外になるかもしれません。個人的には、セットアップ設定ファイルは同じ構成で再セットアップするために保存しておくものであって、カスタマイズをすることが前提なものではないのではないか?と思いますので、Microsoft のサポートにきちんと相談したほうがよいのではないかと思います。

    (項目としては、セットアップ時に変更可能である項目を書き換えているだけですので、SQL Server Components が何も入っていない状態であれば、SQL Server の動作に影響を与えることはないと思います)

    2011年7月22日 7:52
  • 質問への回答ではありませんが、なぜD:ドライブに変更したいのでしょうか?

    Windowsではインストール先によってAPIの動作が変わるものがあります。
    1例を挙げますと、ユーザー インターフェイス特権の分離 (UIPI)では上位の権限のプロセスとやりとりする際の条件として、%ProgramFiles%下にインストールされること、というものがあります。
    この例はSQL Serverには影響ないかもしれませんが、インストール先は変更しないことをお勧めします。(変更するにしても%ProgramFiles%下でのリネーム程度に。)

    2011年7月22日 23:35
  • インストール先を指定できるようになっているのに、どうして指定してはいけないのでしょうか?

    それでは指定できるようになっている意味がありませんし、項目自体をなくしておけば良いだけの話では無いのですか?

     

    CドライブはPCを良く知らないユーザが使用していると、動作に不具合を起すまでいろんなファイルが増加して空きが無くなります。

    良く知らないユーザが使用するものなので、あえてDドライブにインストールしています。

    ローカル内の閉じた環境で使用することを前提としているので、特権の分離なども使う方としては煩わしいです。

     

    2011年7月28日 1:12
  • RESありがとうございます。

    OSがプレインストールされているサーバでも、既に何らかのSQLServer Components が入っている可能性が有るという事ですね。

    SQLServer Components を含んでいるものとは、どんなものが有るのでしょうか。

    何か確認方法をご存知でしたら教えて下さい。

     

    2011年7月28日 1:22
  • ですから、質問されたように、インストール先が指定できなくなっているのでは? 指定できるコンポーネントと指定できないコンポーネントがあるから項目をなくせないのかと想像しています。

    対象OSがWindows Server 2008 R2という事でサーバーのはずです。PCをよく知らないユーザーがサーバーを操作してC:ドライブを溢れさすというのは、サーバー管理者が管理不行き届きで失格でしょう。特権の分離を煩わしがって、PCをよく知らないユーザーにも管理特権を与えてしまうからC:ドライブを溢れさすんでしょうし、言っていることが支離滅裂なような。

    それとあえて「1例を挙げますと」と強調しておいたのですが通じなかったようで残念です。1例を否定しても意味はなく、すべてのパターンを考慮する必要があります。

    というわけで、インストール先は変更しないことをお勧めします。(変更するにしても%ProgramFiles%下でのリネーム程度に。) は特に変わりありません。
    ちなみに、SQL Serverでプログラムよりももっとディスク容量を必要とするデータベースファイル、その置き場所は変更することが可能です。 データベースファイルだけD:ドライブに置かれてはどうでしょう?

    2011年7月28日 2:51
  • こちらで扱っているシステムでは、サーバ管理者が別にいるという前提自体が間違っています。

    サーバ管理者=PCを良く知らないユーザ ということです。

    数百あるそのような形態のシステムのお守りをあなたは行えますか?

    1件ごとに理想的なサーバ管理の仕方を説いてまわるのですか?

     

    2011年7月29日 0:13
  • PCをよく知らないユーザーが管理者としてC:ドライブに大量のファイルを書き込むのですか? それはプログラムコード? データファイル?
    プログラムは今どきのディスク容量で溢れさせるのは困難だと思いますが、もし溢れるのなら構築時のサイジングが間違っているのでしょう。
    データファイルで溢れさせるのであれば、初期構築の際にデータファイルを別ドライブを使用するよう構成しなかったのが問題でしょう。

    いずれにせよ、設計が足りてないと思います。

    もしくは、PCをよく知らないユーザーだとしても管理者としてディスクを溢れさせたのなら、その人に非があるとも言えます。

    2011年7月29日 11:41
  • インストール先を指定できるようになっているのに、どうして指定してはいけないのでしょうか?

    それでは指定できるようになっている意味がありませんし、項目自体をなくしておけば良いだけの話では無いのですか?

     

    CドライブはPCを良く知らないユーザが使用していると、動作に不具合を起すまでいろんなファイルが増加して空きが無くなります。

    良く知らないユーザが使用するものなので、あえてDドライブにインストールしています。

    ローカル内の閉じた環境で使用することを前提としているので、特権の分離なども使う方としては煩わしいです。

     


    市販ソフトでもSQL Server Express Editionを使うものがありますので、それで共通コンポーネントがインストールされていて、それで共通コンポーネントがインストールできない可能性もあります。

    逆に共通コンポーネントが別フォルダにインストールされてしまうと、二重にインストールされてしまいますし、仮にインストールできたとしてもPATHの指定でどのプログラムが動くかわからないため、グレーアウトされるのは(ある意味)正しいインストールルールだと思います。


    あと今回の問題とは別の方法での解決方法ですが…

     > CドライブはPCを良く知らないユーザが使用していると、動作に不具合を起すまでいろんなファイルが増加して空きが無くなります。

    クォータを設定してHDDの使用量を制限すれば解決すると思われます。
    もしくは、逆にユーザーフォルダをCドライブ以外に作成するとか。

    あとHDDが増設できるのであれば、あえてドライブレターを付けずにフォルダにマウントさせることで 見た目上の容量を増やすことができますので、検討してみてはどうでしょうか?

    あとは(あまりお勧めできませんが)仮想メモリのスワップファイルを別のドライブに移動する方法もあります。

    2011年8月3日 4:08
  • あと補足ですけど、データファイルはどのドライブにインストールするようにしていますか?

    SQL Serverのデータベースファイルに比べれば、プログラムファイル自体は微々たる物ですし、Cドライブ以外にインストール場合のリスクの方が大きいような気もしますが…。(昔、MSのオフィス製品でもCドライブ以外にインストールした場合に障害を起こしていますし)

     あとパーティションの構成が不明なので何とも言えませんが、使用しているサーバーがWindows Server 2008 R2ということですので、以前のOSよりはパーティションの再設定はしやすくなっていますので、パーティションサイズを変更するのも一考かと。
    (当然ですが、バックアップは必要です)

     後。SQL Serverのデータファイルではなく、ユーザープロファイルが肥大化してCドライブを圧迫しているのであれば、ユーザープロファイルをDドライブに移動するのが一番楽なような気がします。

    2011年8月3日 8:08