none
Accessの修正&最適化 RRS feed

  • 質問

  • いつも、お世話になります。

    V5です。

     

    Accessで修正&最適化がありますが、SQL Server 2005 Express Editionでは、どのようにして行うのでしょうか?

    それともSQL Server 2005 Express Edition では、 修正&最適化は必要ないのでしょうか?

     

    よろしく、お願いいたします。

    2008年1月25日 9:12

回答

  • SQL Serverにも、テーブル再作成とか、バックアップ&リカバリのような類似の機能はあります。

     

    しかしながら、Accessでいうところの最適化という感じでSQL Serverのテーブル再作成を行う必要ありませんし、修復(修正じゃなくて修復だったはずだけど未確認)についてもAccessのようにバックアップからリカバリを頻繁に行うような製品でもありません。

     

    Express Editionといえでもコア技術はSQL Serverなのですから、Accessでのメンテとはまったく異なると考えたほうがいいでしょう。

     

     

     

     

    2008年1月27日 10:21
  • 初音玲様、

    回答ありがとう、ございます。

     

    そのとおりで、修復の間違いでした。失礼しました。

     

    現在、Access2003のデータベースで、結構、修復、最適化が

    発生します。

    SQL Server 2005のほうが、Accessのデータベースより

    壊れにくいということですね。

    2008年1月27日 16:15

すべての返信

  • SQL Serverにも、テーブル再作成とか、バックアップ&リカバリのような類似の機能はあります。

     

    しかしながら、Accessでいうところの最適化という感じでSQL Serverのテーブル再作成を行う必要ありませんし、修復(修正じゃなくて修復だったはずだけど未確認)についてもAccessのようにバックアップからリカバリを頻繁に行うような製品でもありません。

     

    Express Editionといえでもコア技術はSQL Serverなのですから、Accessでのメンテとはまったく異なると考えたほうがいいでしょう。

     

     

     

     

    2008年1月27日 10:21
  • 初音玲様、

    回答ありがとう、ございます。

     

    そのとおりで、修復の間違いでした。失礼しました。

     

    現在、Access2003のデータベースで、結構、修復、最適化が

    発生します。

    SQL Server 2005のほうが、Accessのデータベースより

    壊れにくいということですね。

    2008年1月27日 16:15
  •  V5 さんからの引用

    SQL Server 2005のほうが、Accessのデータベースより

    壊れにくいということですね。

     

    Accessのデータベースで修復する必要が多いという事は、ネットワーク越しに使っていたり、ファイル共有して同時に複数人で使用したりしていませんか?

    Accessデータベースは1台のマシン上で共有などせずにスタンドアロンで使うことで初めて威力を発揮する製品であり複数人からの同時使用を前提とはしていません(現状は結構無理して同時使用しようとおもえばできているレベルだと思って下さい)。

    一方、SQL Serverはスタンドアロン前提ではなくネットワーク越しに複数人から同時に使用する事を前提としていますから、その生い立ちや機能は全く別物になります。

    両者に共通しているのは、データをテーブルという形で保管しSQL文でデータの参照、更新、追加、削除ができるというくらいの話だと考えてもいいでしょう。

     

    2008年1月28日 1:32
  • そのとおりでございます。

     

    Accessは複数人からの同時アクセスは不向きなのですね。

    勉強になり、ありがとうございました。

     

    2008年1月28日 7:55
  • Access の 最適化 (という部分)に機能的に一番近いのは,

    データベースの圧縮

    あたりを読むとあります。(実際は機能的/効果的には別物です)

     

    Accessの場合,最適化でMDBファイルが縮小する際,

    テーブルの主キー順にファイル内でレコードが並び替えられますが,

    SQL Server の場合は,

    もともと インデックスの(ツリーの)末端(リーフ)が そのままデータページとなる

    構成のインデックス(クラスタ・インデックス)としてある場合が多いと思うので,

    その場合は,もともと主キーが近いものどおしで(ページに)収まっています。

    主キー順にキッチリ追加して行ってるだけの場合を除いては,

    必ずしも縮小したほうがいいということにはならないので,

    Accessとはその後の効果が微妙に異なる場合があります。

    例えば,

    クラスタインデックス(インデックスツリーの末端(リーフ)が そのままデータページ)

    を採用しているテーブルの場合,

    新規行がキーの隙間に入っていくようなデータや

    修正時にデータが膨れ上がるようなデータが多々ある場合は,

    データページが縮小されすぎていて隙間がないと,

    (インデックスツリーの再構成が必要になってきたりすると)

    余計に負荷ががかかるようになる可能性もあります。

    SSMS (SSMSE) からやる際に,

    データベースの圧縮で,

    圧縮アクションで,空き領域を%指定できるようになってるのはそのためです。

     

    ただ,雰囲気としては,最適化 に似ています。

     

     

    # 圧縮 と訳されていますが,

    # compress (compression) でなく shrink (shrinking)なので,

    # 意味的には 縮小する(させる)/縮小 という程度のことです。

    # 'いわゆる圧縮' しているわけではないです。

     

     

    2008年1月28日 14:57
  • yayadon様、V5です。

     

    データベースの圧縮ですね。(メモ)

    ありがとう、ございました。

    2008年1月29日 10:50