WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

canvas の画像をアップロード

by WebSurfer 2015年7月2日 16:27

クライアントの PC にある画像を HTML5 の File API を利用して取得し、それを指定のサイズに縮小して HTML5 の canvas に描画し、canvas に描画された画像を jQuery.Ajax を使って Web サーバーにアップするサンプルを書きます。

2022/11/20 追記: ASP.NET の FileUpload コントロールや jQuery は使わないで、html と JavaScript のみを使って同様な機能を実装した記事を「canvas の画像をアップロード (その 2)」に書きました。

canvas の画像をアップロード

大まかな手順は以下の通りです。詳しくは下のサンプルコードとそれに書いたコメントを参照ください。

  1. クライアントによる画像ファイルの選択は ASP.NET の FileUpload コントロール(普通の HTML の <input type="file" ... /> でも可)を利用する。
  2. FileUpload コントロールで画像ファイルが選択されたタイミングで、HTML5 File API の FileReader オブジェクトに readAsDataURL メソッド を使って選択された画像ファイルを読み込む。
  3. FileReader の result プロパティ を使って、読み込んだ画像ファイルを Data url 形式("data:image/jpeg;base64, ..." という文字列)で取得し、それを image オブジェクトの src 属性に設定する。
  4. その image オブジェクトを HTML5 の canvas に drawImage メソッド を使って描画する。その際、描画する画像の最大サイズの制限を設け(今回のサンプルでは 500 x 500 とした)、それに入る場合はそのまま、入らない場合は幅・高さどちらか大きい方を 500px に縮小し他方をその縮小率と同じに縮小(要するに縦横比を保ったまま 500 x 500 に入るよう縮小)する。
  5. canvas 上の縮小後の画像データを取得して Web サーバーに非同期で送信するメソッドを作る。canvas からの画像データの取得は toDataURL メソッド を用いる。Data url 形式で取得できるので、それを jQuery.Ajax を用いて JSON 形式で送信する。(BASE64 でエンコードされているので、バイナリ形式よりサイズが約 1.3 倍大きくなってしまうが・・・)
  6. <input type="button" ... /> タイプのボタンを配置し、その onclick 属性に上記のメソッドを設定する。
  7. 非同期でクライアントから送信された BASE64 形式の画像データは、.aspx ページに静的メソッドを追加してそれで受け、デコードしてバイナリ形式に戻してファイルに保存する。
  8. オマケとして、画像ファイルのサイズを 500,000 bytes に、ファイルのタイプを image/jpeg に制限した。

サンプルコードは以下の通りです。自分の開発環境の IE9 では File API が使えないので試してませんが、Firefox 38.0.5, Chrome 43.0.2357.130 m, Opera 12.17 で期待通り動くことは確認しました。

同様なコードを 実験室 にアップしましたので、よろしければ実際に動かして試してみてください。画像ファイルのサイズを 500,000 bytes、タイプを image/jpeg に制限しているので注意してください。(実験室ではファイルのアップロードと保存はしていません。代わりに短い文字列を応答として返すようにしています)

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Web.Services" %>
<%@ Import Namespace="System.IO" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">
  // jQuery.Ajax で POST された画像データを受けるためのメソッ
  // ド。public static にして WebMethodAttribute 属性を付与
  [WebMethod]
  public static string ReceiveImage(string imgBase64)
  {
    // 文字列先頭の "data:image/jpeg;base64," を除去。
    imgBase64 = 
      imgBase64.Replace("data:image/jpeg;base64,", "");

    // BASE64 エンコードされた画像データを元のバイト列に変換
    Byte[] imgByteArray = Convert.FromBase64String(imgBase64);

    // ファイル格納フォルダ FileUploadTest の物理パスを取得
    string savePath = 
      HttpContext.Current.Server.MapPath("~/FileUploadTest/");

    // ファイル名を設定
    string filename = 
      "img" + DateTime.Now.ToString("yyyyMMddHHmmss") + ".jpg";

    // ファイル格納フォルダ FileUploadTest に画像ファイルを保存
    File.WriteAllBytes(savePath + filename, imgByteArray);

    return "ファイル名 " + filename + " として保存しました。";
  }
</script>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
  <title>Canvas Image Upload</title>
  <script src="Scripts/jquery-1.8.3.js" type="text/javascript">
  </script>
  <script type="text/javascript">
  //<![CDATA[
    // 画像ファイルのサイズ制限を 500,000 bytes、タイプ制限を
    // image/jpeg とする
    var maxFileSize = 500000;
    var allowedContentType = "image/jpeg";

    // アップロードする画像のサイズを 500 x 500 以下とする
    var maxWidth = 500;
    var maxHeight = 500;

    // HTML5 File API の FileReader を利用して FileUpload で
    // 選択された画像ファイルを読み込み、その画像の Data url
    // 形式文字列を取得。それを image オブジェクトの src 属性
    // に設定する。その際 image.onload イベントが発生するので
    // そのイベントにコールバック関数(リスナ)をアタッチ。そ
    // のリスナの中で image オブジェクトが保持する画像をにサ
    // イズ制限以下に縮小して canvas 描画する。以下の 3 行は
    // そのための準備
    var fileReader;
    var image = new Image();
    image.onload = DrawImageOnCanvas;

    // document の読み込み完了後に { } 内の処置を行う
    $(function () {
      // ブラウザの HTML5 File API サポートを確認
      if (window.File && window.FileReader && window.FileList) {
        fileReader = new FileReader();

        // FileReader オブジェクトに画像を読み込むメソッド
        // readAsDataURL は非同期で動くので、読み込み完了の
        // イベントを待ってリスナで処置する必要がある。 
        // readAsDataURL で読み込みが完了すると onloadend 
        // イベントが発生するので、それにリスナをアタッチし、
        // そこで FileReader から Data url を取得し image
        // オブジェクトの src 属性に設定する。
        fileReader.onloadend = function () {
            image.src = fileReader.result;
        };

        // FileUpload1 でファイルの選択が完了すると change
        // イベントが発生するのでそれにリスナをアタッチし、
        // そこで以下の処置を行う。
        $("#<%=FileUpload1.ClientID%>").change(function () {
          var fileUpload =
            document.getElementById("<%=FileUpload1.ClientID%>");

          // ファイルが選択されているか、選択されたファイル
          // のタイプ/サイズは制限に入っているかを確認
          if (ClientValidate(fileUpload) == false) {
              $('#Button1').attr('style', 'display:none');
              return;
          }

          // fileReader オブジェクトに FileUpload1 で選択
          // された画像ファイルを読み込む
          fileReader.readAsDataURL(fileUpload.files[0]);
        });
      }
      else {
        $("#<%=FileUpload1.ClientID%>").
            attr('style', 'display:none');
        $('#mycanvas').attr('style', 'display:none');
        $('#result').text('File API がサポートされてません。');
      }
    });

    // ファイルの確認のためのヘルパ関数
    function ClientValidate(fileUpload) {
        if (fileUpload.files[0] == null) {
            alert("ファイルが未選択です。");
            return false;
        }

        if (fileUpload.files[0].type != allowedContentType) {
            alert("選択されたファイルのタイプが" + 
                allowedContentType + "ではありません。");
            return false;
        }

        if (fileUpload.files[0].size > maxFileSize) {
            alert("ファイルのサイズが制限の " + 
                maxFileSize + " バイトを超えています。");
            return false;
        }

        return true;
      }

      // 上で定義した image オブジェクトの src 属性に Data url
      // が設定されると発生する onload イベントのリスナ。ここ
      // で image 要素から canvas を描画する。
      function DrawImageOnCanvas( )
      {
        // オリジナル画像のサイズ
        var w = image.width;
        var h = image.height;

        var targetW, targetH;
        var context = 
          document.getElementById('mycanvas').getContext('2d');

        if (w <= maxWidth && h <= maxHeight) {
            // w, h ともに制限 maxWidth, maxHeight 以内 ⇒
            // そのままのサイズで canvas に描画
            $('#mycanvas').attr('width', w);
            $('#mycanvas').attr('height', h);
            context.drawImage(image, 0, 0);
        }
        else if (w < h) {
            // w, h どちらかが制限オーバーで h の方が大きい ⇒
            // 高さを maxHeight に縮小
            targetH = maxHeight;
            // 幅は高さの縮小比率で縮小
            targetW = Math.floor(w * targetH / h);
            $('#mycanvas').attr('width', targetW);
            $('#mycanvas').attr('height', targetH);
            context.drawImage(image, 0, 0, targetW, targetH);
        }
        else {
            // w, h どちらかが制限オーバーで w の方が大きい ⇒
            // 幅を maxWidth に縮小
            targetW = maxWidth;
            // 高さは幅の縮小比率で縮小
            targetH = Math.floor(h * targetW / w);
            $('#mycanvas').attr('width', targetW);
            $('#mycanvas').attr('height', targetH);
            context.drawImage(image, 0, 0, targetW, targetH);
        }

        $('#Button1').attr('style', 'display:inline-block');
      }   

      // canvas の画像データを取得して jQuery.Ajax で送信。
      // クライアントからサーバーへ送信できる JSON 文字列の
      // 長さは、デフォルトで 102,400 文字に制限されている。
      // 制限を越える場合 web.config の jsonSerialization 
      // 要素の設定によって変更が必要。
      function uploadImage() {
        var context = 
          document.getElementById('mycanvas').getContext('2d');
        var url = context.canvas.toDataURL("image/jpeg");
            
        $.ajax({
            type: "POST",
            url: "0118-CanvasImageUpload2.aspx/ReceiveImage",
            data: '{"imgBase64":"' + url + '"}',
            contentType: "application/json; charset=utf-8",

            success: function (data) {
                // .NET 3.5 で追加された d パラメータの処置
                if (data.hasOwnProperty('d')) {
                    data = data.d;
                }
                $('#result').text(data);
            },

            error: function (jqXHR, textStatus, errorThrown) {
                $('#result').text('textStatus: ' + textStatus +
                       ', errorThrown: ' + errorThrown);
            }
          });
      }
  //]]>
  </script>
</head>
<body>
  <form id="form1" runat="server">
  <div>
    <asp:FileUpload ID="FileUpload1" runat="server" />
    <input id="Button1" type="button" value="Upload" 
        style="display:none;"
        onclick="javascript:uploadImage();" />
    <br />
    <canvas id="mycanvas" width="500" height="500"></canvas>
    <div id="result"></div>
  </div>
  </form>
</body>
</html>

上のコメントにも書きましたが、クライアントからサーバーへ送信できる JSON 文字列の長さは、デフォルトで 102,400 文字に制限されています。制限を越える場合 web.config の jsonSerialization 要素の設定によって変更が必要となりますので注意してください。以下のように設定します。(数字 300000 は実際にあわせて変更してください)

<configuration>
  <system.web.extensions>
    <scripting>
      <webServices>
        <jsonSerialization maxJsonLength="300000"/>
      </webServices>
    </scripting>
  </system.web.extensions>
</configuration>

Tags: ,

Upload Download

ASP.NET 最大要求数

by WebSurfer 2015年6月26日 14:39

IIS7 以降で利用できる 統合パイプラインモードでは、ASP.NET が扱うことができる最大要求数は、requestQueueLimit(デフォルトで 5,000)で決まるという話を書きます。

ASP.NET 最大要求数

この件に関して自分が参考にした Microsoft のサイトの記事は以下のとおりです。これらをベースに話をします。

  1. <applicationPool> 要素 (Web 設定)
  2. ASP.NET Thread Usage on IIS 7.5, IIS 7.0, and IIS 6.0
  3. IIS 7 での ASP.NET 2.0 の互換性に影響する変更点

なお、統合パイプラインモードかクラッシックモードかによって話が違ってきます。ASP.NET のバージョンによっても話が違ってきます。以下の話は統合パイプラインモードで ASP.NET 2.0 以降のバージョンの場合ですのでご注意ください。

(クラシックモードや IIS6 の場合は上の参考記事 2 を見てください。手抜きですみません)

上の参考記事の 1 に書いてあるとおり、統合パイプラインモードで ASP.NET 3.5 以降の場合、aspnet.config ファイルでの applicationPool 要素の設定が有効になります。

applicationPool 要素は以下の 3 つの属性を持っています。それぞれの詳しい説明は上の参考記事 1 を見てください。以下の ( ) 内の数字はデフォルト値です。

  • maxConcurrentRequestsPerCPU (ASP.NET 3.5: 12, ASP.NET 4: 5000)
  • maxConcurrentThreadsPerCPU (0)
  • requestQueueLimit (5000)

ASP.NET 2.0 では applicationPool 要素は使用できませんが、代わりに、レジストリで MaxConcurrentRequestsPerCPU(デフォルトで 12)と、web.config で processModel 要素 の requestQueueLimit 属性(デフォルトで 5,000)の設定が有効になります。

maxConcurrentRequestsPerCPU については、上の参考記事 1 によると、この設定値を超えると ASP.NET によって制御される要求調整がかかるということです。(ASP.NET 4 のデフォルト値 5,000 では実質的に要求調整はかからないということらしいです)

要求調整とは、上の参考記事 2 にある "the CLR Threadpool is still controlled by the processModel configuration settings (autoConfig, maxWorkerThreads, maxIoThreads, minWorkerThreads, and minIoThreads). And autoConfig is still enabled, but its modifications to httpRuntime/minFreeThreads and httpRuntime/minLocalRequestFreeThreads do nothing, since the application-level queues do not exist." のことだと思われます。

ちなみに、maxConcurrentRequestsPerCPU を 0 に設定すると、IIS I/O スレッドから CLR スレッドへの切り替えは行われず、そのまま IIS I/O スレッドで処置されるそうです。

maxConcurrentRequestsPerCPU の設定値を超えると、上で言う要求調整がかかると思いますが、要求を受けるたび CLR スレッドプールから空いているスレッドを借り出して、そのスレッドで要求を処理するという動作には変わりないはずです。ただし、CLR スレッドプールにあるスレッドの数(要求調整で変わる?)には制限があるので、空いているスレッドがなくなると要求はキューに溜まるということになります。

従って、ASP.NET が扱うことができる最大要求数は、最終的に requestQueueLimit の設定値(デフォルトで 5,000)で決まるということになります。上の参考記事の 2 にも以下のように書いてあります。

"As a final remark, please note that the processModel/requestQueueLimit configuration limits the maximum number of requests in the ASP.NET system for IIS 6.0, IIS 7.0, and IIS 7.5. This number is exposed by the "ASP.NET/Requests Current" performance counter, and when it exceeds the limit (default is 5000) we reject requests with a 503 status (Server Too Busy)."

(注: 上で "processModel/requestQueueLimit" と言っていますが、ASP.NET 3.5 以降であれば applicationPool 要素の requestQueueLimit の設定の方が優先されます)

"in the ASP.NET system" の system というところに注意してください。system = アプリケーションプールらしいです。根拠は、上の参考記事 1 の requestQueueLimit 属性の説明に "アプリケーションプール内のアプリケーションに対する要求の累積数は、この設定によって制限されます" と書いてあるところです。

上の参考記事の 2 によると、一般的にはデフォルトのままでいいそうです。ただし、処理に時間がかかるアプリケーション(例えば、他のサイトの Web サービスとの通信に 100 ms かかるような)で、多くの同時要求を処理する場合(多いというのは 12 ~ 5,000 per CPU とのこと)は、以下のような設定の変更した方がいいそうです。

  1. ASP.NET 2.0 では、レジストリの設定を変更して MaxConcurrentRequestsPerCPU を 5000 にする。
  2. ASP.NET 3.5 では、aspnet.config ファイルで applicationPool 要素の maxConcurrentRequestsPerCPU 属性を 5000 に設定する。

    レジストリで設定しても良いが、aspnet.config ファイルと両方に設定した場合、aspnet.config ファイルの設定が優先されるそうです。
  3. ASP.NET 4 以降では、maxConcurrentRequestsPerCPU はデフォルトで 5000 なので何もする必要はない。
  4. HTTP.sys キュー(デフォルトで 1,000)を増やす。

    これは requestQueueLimit で設定する CLR スレッドプールのキューの制限ではなく、IIS I/O スレッドのキューです。IIS Manager を開いて、Application Pool の詳細設定で表示される[キューの長さ]で設定できます。アプリケーションを x64 で動かしていて、2GB 以上のメモリがある場合は 5000 でいいそうです。
  5. 他のサイトの Web サービスなどと HTTP で通信している場合は、そのサービスへの最大接続数を connectionManagement 要素 の maxconnection を調整して増やす。

    processModel/autoCongfig によって 12 per CPU に設定されるそうです。調整の仕方は上の参考記事 2 を参照してください。
  6. バースト的に同時要求が増えることがある場合は、アプリケーションを非同期にする。

    その理由は、CLR スレッドプールのスレッドの数を急には増やすことができないからだそうです。「非同期」の意味は MSDN の記事「ASP.NET の非同期/待機の概要」を見てください。

maxConcurrentRequestsPerCPU 等の値は、既存の aspnet.config には何故か applicationPool 要素は設定されていないのですが、ASP.NET 4 以降であれば以下のようにして取得できます。上の画像はそれらの値を表示したものです。(applicationPool 要素の requestQueueLimit 要素の設定値の取得方法は分かりませんでした)

int maxConcurrentRequestsPerCPU =
        HostingEnvironment.MaxConcurrentRequestsPerCPU;
int maxConcurrentThreadsPerCPU =
        HostingEnvironment.MaxConcurrentThreadsPerCPU;
int requestQueueLimit =
        ((ProcessModelSection)WebConfigurationManager.
        GetSection("system.web/processModel")).
        RequestQueueLimit;

Tags:

ASP.NET

データベースの復元

by WebSurfer 2015年6月14日 20:31

このホームページ / ブログに利用しているホスティングサービス会社から、SQL Server データベースの���グファイルのサイズが数 10 GB に肥大化していて破損している可能性があるので対応して欲しいとの連絡がありました。

自分が壊したわけではない(はず)なのですが、ホスティングサービス会社では復元のための作業はやってくれないそうなので、やむを得ず自分でやりました。その手順を備忘録として書いておきます。

まず、ホスティングサービス会社が提供している myLittleAdmin というツールを利用してバックアップを作成し、それをダウンロードします。

myLittleAdmin を利用してバックアップ作成

ファイルサイズが数 10 GB と巨大なので、バックアップファイルの作成とダウンロードにとんでもなく時間がかかるかと思っていましたが、全然そんなことはなかったです。

バックアップファイル (.bak) の作成にはほとんど時間はかかりません。生成された .bak ファイルのサイズは 38,666 KB(GB ではなくて)でした。ダウンロードには、当たり前ですが、ファイルサイズに似合った時間はかかりましたが。

.bak ファイルを C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup に保存。UserDatabase データーベースは、自分の PC の SQL Server 2008 Express に作成済み、アタッチ済みだったものがあったので、それを復元してみました。

復元作業は、SQL Server Management Studio を使って、マイクロソフト公式解説書「一目でわかる Microsoft SQL Server 2008」の 5 章の「6 データベースを復元するには」の手順に従って行いました。

しかし、デフォルト設定のままやると UserDatabase の .bak ファイルが違うという意味(正確なメッセージは忘れました)のエラーが出て復元できません。

本にはデフォルト設定のままでもよさそうに書いてありましたが、[オプション]タブの[復元オプション]の項目で[既存のデータベースを上書きする (WITH REPLACE)(O)]にチェックを入れないとダメでした。

SQL Server のバージョンの違い(ホスティングサービスは 2005、自分の開発環境は 2008)は復元には問題なかったです。

復元されたデータベースのファイルサイズは、エクスプローラで見て UserDatabase.mdf が 39,296 KB、USERDATABASE.LDF が 51,090,368 KB でした。

開発マシンの Web アプリからデータベースに接続し、ざっと内容を見てみたが、正しく復元されていてデータベースファイルには問題がない様子。

問題はやはり、ホスティングサービス会社が言うように、USERDATABASE.LDF が 51,090,368 KB と肥大化していること(だけ?)のようです。

次に、トランザクションログの切捨てを行うため、トランザクションログをバックアップします。(切捨ては、ログファイルに再利用可能な領域を広げるだけで、ファイルサイズを小さくするわけではないそうです)

マイクロソフト公式解説書「一目でわかる Microsoft SQL Server 2008」の 5 章の「3 トランザクションログをバックアップするには」の手順に従って、userdatabaselogfile_20150614.bak というファイル名を指定してバックアップ。バックアップは成功し(正常に実行されましたとのダイアログが出る)、2,954 KB の .bak ファイルが作成されました。

しかし、やはりログファイル USERDATABASE.LDF のサイズは変わりません。ファイルサイズを小さくするために DBCC SHRINKFILE (UserDatabase_log, 5) を実行してみます。

(注:ファイル名には SELECT * FROM sys.database_files で取得できる UserDatabase_log という名前を使わないとダメでした。USERDATABASE.LDF という名前を使うと sys.database_files でファイルが見つからないというエラーになります)

このときは、"クエリが正常に実行されました" とは出るものの、[メッセージ]タブをクリックして見ると、"ログ ファイル 2 (UserDatabase_log) を圧縮できません。ファイルの末尾にある論理ログ ファイルが使用中です" というエラーメッセージが出ます。理由は不明です。(汗)

DBCC SQLPERF(LOGSPACE) を実行してみると以下の結果になりました。ファイルサイズは多少は小さくなったもののまだ数 10 GB のオーダーです。

Log Size (MB): 48474.99
Log Space Used (%): 0.6307064

エクスプローラで見ると、ファイルサイズは、UserDatabase.mdf が 39,296 KB、USERDATABASE.LDF が 49,638,400 KB(DBCC SHRINKFILE 実行前は 51,090,368 KB)で、やはりサイズの縮小に失敗しています。

ここで諦めては何なので、もう一回ログファイルのバックアップからやってみるました。前回作成した userdatabaselogfile_20150614.bak に上書きしたことが異なるだけで、その他の手順は前回と同じです。前回と同様に処理は正常に終わります。.bak ファイルのサイズは 2,954 KB ⇒ 204,048 KB になりました。

DBCC SQLPERF(LOGSPACE) を実行してみると以下の結果となり、Log Size (MB) は同じながら、Log Space Used (%) が一桁下がっています。

Log Size (MB): 48474.99
Log Space Used (%): 0.04509413

DBCC SHRINKFILE (UserDatabase_log, 5) を実行してみると、今度は "圧縮できません" というエラーメッセージは出ません。再度 DBCC SQLPERF(LOGSPACE) を実行してみると以下の結果となり、Log Size (MB) が大幅に下がっていました。

Log Size (MB): 5.117188
Log Space Used (%): 14.37023

DBCC SHRINKFILE (UserDatabase_log, 5) の 5 というのは、ファイルサイズが 5MB になるよう領域を開放することを意味するので、ほぼ期待通りの結果です。

何故一回目がうまく行かなかったのかは謎です。(汗)

開発環境でこの記事をポストして正常に表示されることを確認してから、SQL Server Management Studio で .bak ファイルを作成し、myLittleAdmin を利用して本番環境の UserDatabase を復元・・・を試みましたが、"デバイス 'xxx.bak' のメディア ファミリが正しい形式ではありません。SQL Server はこのメディア ファミリを処理できません" というエラーメッセージが出て失敗に終わります。(涙)

心当たりがないか、ホスティングサービス会社に問い合わせ中です。SQL Server 2008 で作成したバックアップファイルで SQL Server 2005 のデータベースの復元は間違いなくできるのでしょうか? (バージョンの違いの件は、事前にホスティングサービス会社に問合せていて、「恐らく大丈夫」とのことでしたが・・・)


【2015/6/16 追記】

本番環境の UserDatabase の復元に失敗する理由は、やはり SQL Server のバージョンの違いでした。

MSDN ライブラリの記事 復元と復旧の概要 (SQL Server) の「注意」に "SQL Server 2008 のバックアップを以前のバージョンの SQL Server で復元することもできません" とはっきり書いてありました。

ホスティングサービス会社のサポート担当の人によると、彼ら自身で実際に SQL Server 2008 R2 で作業して復元は可能なことは確認したとのことでしたが、それは SQL Server 2008 R2 では更新等何も行わなかったからで、更新を行うと同じエラーとなって失敗に終わるそうです。

結局、自分の開発マシンに SQL Server 2005 Developer Edition をインストールして、上に書いたのと同様な手順で復元作業を行った結果、myLittleAdmin の復元ウィザードで SQL Server 2005 Std のデータベースの復元ができました。

ただし、修復用の .bak ファイルを作った時のログファイルのサイズは 5MB 程度だったのが、時間と共に増えていっているのが気がかりです。

myLittleAdimin で SELECT * FROM sys.database_files クエリを実行して調べたログファイルの size は、復元した時: 5MB ⇒ その約 11 時間後: 48MB ⇒ その約 1 時間後: 64MB ⇒ その約 1 時間後: 70MB と増えていくのが解せません。

ちなみに、データベースファイルの size は 4912(x 8 = 39,294 KB)でローカル環境から変化していません。また、復元した UserDatabase に対して DBCC CHECKDB を実行してみましたが、エラーなしという結果でした。

何かまだ問題があるような気がしています。ホスティングサービス会社に、サーバーに障害や設定上の問題等はないか確認依頼中です。

上に、「何故一回目がうまく行かなかったのかは謎です」と書きましたが、SQL Server 2005 を使って作業した時も同じで、その原因はログファイルが壊れていて、そこが修復できていないからではないかという気もしています。


【2015/6/17 追記】

上の【2015/6/16 追記】に書きましたように、ホスティングサービス会社にサーバーに障害や設定上の問題等はないか確認をお願いしていましたが問題ないとの返答がありました。

昨日はデータベースの更新は行ってないのにログファイルの size がどんどん増えていくのが解せなかったのですが、今日 size を調べてみたところ落ち着いてきていました。もう少し様子を見て、まだ問題があるようでしたらまたここに書くことにします。

Tags:

SQL Server

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。

Calendar

<<  2024年3月  >>
252627282912
3456789
10111213141516
17181920212223
24252627282930
31123456

View posts in large calendar