堀川です、おはようございます


-----Original Message-----
From: Kohichiroh Ohta [mailto:who@example.co.jp]
Sent: Tuesday, March 07, 2006 4:42 PM
To: who@example.ne.jp
Subject: [ml-msde-beg:01785] RE: データベースの運用やその他について（ RE:
Re: プライマリファイルグループがいっぱい）


>SQL Server 2000 での共用サービスは
>容易にサービスを混乱させられると言うことですね。

「サービスを混乱させられる」というのではなく、データベースサーバーを
安定的に動かすのが難しいという意味になります。

SQL Server 2000 に、SQLServer認証でログインを許可するアカウントを
作成し、その人の専用データベースを準備します。

データベースの上限値は、ファイルの拡張プロパティで制限ができます。

このファイル拡張制限によって、その人のデータベースの上限を
押さえ込むことが可能になり、サーバー管理者にとっては楽になります。

ところが問題は、tempdbを、ログインユーザ全員で共有で使われる
ことによる弊害があります。

具体的に言えば、一時テーブルの作成権限の設定ができません。

create table #tmp( id int identity(1,1) , dt char(8000)  default ' ' )
while( 'A' = 'A' )  insert into #tmp default values

このようなSQL文を投入されると、それで、データベースサーバーは
ダウンする可能性があります。

一時テーブルは、tempdbの中に作成され、通常、tempdbのファイル
サイズ制限は、設定をしません。
このため、DISKが一杯になるまで、レコード挿入処理を永遠に
繰り返します

もちろん、このようなSQL文を投入するユーザは、普通はいません。
ただストアドプロシージャ等の作成を間違えて、このような無限ループを
作ってしまうことはあるでしょう。

結果的に、悪意の有る無しに関らず、データベースサーバーの運営に
影響を及ぼします

重要なことは、SQL Server 2000 に、ログインができるユーザは誰でも
このようなSQL文を実行することができる、潜在的な脅威があるという
ことです。

ですから、データベースサーバーの共用システムを、SQL Server 2000で
実現させようとすると、サーバー管理者が張り付いて、その運営状況を
監視しなければいけません。



>ちょっと興味があるので試してみたいです。
>ただ、私はIISの知識がないので無理なのでは思うのですが
>今後、勉強したら遊んでみます。

WebMatrixHosting サービスは、本来の目的は、ASP.NETを
普及させるものですが、別にASP.NETは使わなくても構いません。

Enterprise Manager やクエリアナライザ等で、データベースサーバーに
接続して遊んで見て下さい。

多数のユーザが常時ログインしています。



>ただトランザクションログについてなのですが
>実は最初はフルモードにしていたのですが
>時々トランザクションログファイルがいっぱいになってしまって
>かえって業務に支障をきたす場面があったので
>今はシンプルモードにしてしまっています。

それだと、データベースが壊れたときに、データ損失が発生します。
せっかく信頼性が高いデータベースサーバーを使っているのですから、
復旧モードは、「フル」にした方がよいと思います



>この問題は、まず毎日のバックアップを
>ジョブを登録することで自動化し
>そのジョブのトランザクションログのバックアップ部分で
>ログを切捨てる設定にしていれば解決しますよね。

その通りです。

トランザクションログを切り捨てした後に、全体バックアップを実行する命令
をジョブに登録して下さい

　　BACKUP 　LOG 　DBName 　 WITH  　TRUNCATE_ONLY

　　BACKUP  DATABASE  DBName  TO DISK='BackupFileName

を実行します。


データベースのバックアップ方針が、全体バックアップで済むようであれば
トランザクションログ管理は、しなくてもよいと思います
（適時に、切捨てすればよい）

ただ時々、
　　　　　　　　　　　「過去のデータを見たい」
などのような要求は、許可できません。
それを認めると、継続的なログ管理が必要になります。


トランザクションログが必要になるのは、データベースが壊れたときです。

直近の全体バックアップを実行してから、壊れる直前までの、データベースの
更新記録を、ログから吸い出すときに使います。

この作業のとき、SQL Server 7 では、問題があったわけです。

NO_TRUNCATE でバックアップできず .MDF がなくなる
http://support.microsoft.com/default.aspx?scid=kb;ja;218739

MDFが壊れたら、ログのバックアップができません。
でも、データベースが壊れているのに、MDFが無傷であるはずはありません。

この問題が、SQL Server 2000では、治ったわけです。
MDFの状態に関らず、ログのバックアップができるようになりました。

このような意味から、トランザクションログファイルは絶対に壊してはいけない
ファイルです。




>すみません、ハードウェアについてあまり詳しくないのですが
>運用中のサーバーの仕様書にディスクアレイコントローラというのがあるようで
す。
>これはRAIDのことでしょうか？

そうです。
ただ、「ディスクアレイコントローラ」にも様々な種類があるので、使うときは十分
に
調査してから使って下さい。

コンピュータ本体のCPUを借用して、演算処理を行なうものは、使わない方が
よいでしょう。
最近のエントリサーバー（格安サーバー）のRAIDは、本体のCPUを必要とします。



>> それが守られれば、例えば、私はまだ使ったことが無いのですが
>>      http://www.gigabyte.co.jp/nippon/i-ram/iram-m.html
>> ギガバイトのこのRAMの中に、MSDE2000のデータファイルを入れておく
>> という手法も考えられます

上記の製品について、誤解していました。

PCIバスを使ったRAM-DISKかと思ったのですが、そうではなくて、シリアルATAの
ハードディスクを模倣する製品です。
PCIからは電源を取っているだけです

ですから、最大転送能力は、シリアルATAの能力に依存しているわけです。

秋葉原周辺で、本体は、２万円弱で売っていますね
でも別途メモリボードが必要ですから、４GBにすると、１０万円弱になりそうですね




>>  どこまでの被害であれば、どのような事前対策をしておく必要があるのかを
>> 設計し備えておく必要があります。
>> 発生する障害ごとに、事前の準備作業と、復旧手順を、表にまとめておくと
>> 慌てずに済みます
>
>正直に言いますと、そのような設計はやったことがありません。
>ただ「いつ壊れるか分からない」という認識があるのなら
>当然やっておくべきことだと思います。
>この表を見てみたいですが、無理ですか？

顧客のシステムごとに設計しますから、公開するにはちょっと難しい。
ただ、基本は、
                この装置が壊れたら、どう対処するの？
を考えていくことです



>もしも障害が発生してしまった場合は
>もちろん、可能な限りの復旧作業を行うつもりですが
>どこか「壊れたんだから仕方ないじゃない」で
>事後承諾してもらうという考えが、正直ありました。
>反省して、事前に説明しておきたい思います。

もちろん、事後承諾で「済む」ものと「済まない」ものがあります。
その見極めが大事です。

事後承諾で「済む」システムに対して、コストを余計に掛けるのは
無駄だと思います。

マシンが壊れたときに、その辺にあるクライアントを急きょインストールして
サーバーに仕立てて、数時間後に業務再開できるまで、ユーザが
我慢できるのであれば、事後承諾で「済む」システムと言えるでしょう。

数時間じゃ我慢できないようなお客様であれば、事後承諾で「済まない」
システムと言えるかもしれません。

そのシステムを使っているユーザ側の責任者の方に、
　　このサーバーが壊れたとき、業務を止められる時間はどれくらいですか？
と聞いてみるのが一番よいと思います。




>予算を付けてくれなかった側の責任？

そうです、
　　　　　　お金を出さないのが悪い
と思います



>DBA管理者としては、そういう訳にはいかないですよね。
>厳しいですね。

ただ、現実は、こっちですね

だからDBA管理者の良心として、「データ損失」だけは避けるよう
努力します。

業務を止めても、
                     データが無くなってしまった
だけは、避けなければいけません。

ですから、バックアップだけは、繰り返し繰り返し実行するのが
よいと思います


------------------------------------
Epata-IT/日本技術ソフト開発
  　    　堀川　明  (Akira Horikawa)
    ０３月０９日（木曜日）　１０時５６分記
        mailto:who@example.ne.jp
        http://www.horikawa.ne.jp/msde/