We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 26012
    • 324 Posts
    調査の途中経過 その2)

    mysql_query Unable to save result ・・・ という警告は、結構出やすいのかもしれないですね。
    http://www.tecaweb.net/ とか
    http://www.bmath.org/xoops/modules/weblinks/singlelink.php?lid=30 とか (ソースの一番下)

    http://bugs.php.net/bug.php?id=11765 ではバグのような報告もありますし・・・

    「生ログ採取は厳しそう」、は了解。違ったアプローチで調べましょう。
      • 19592
      • 56 Posts
      >sama55 さん
      調査ありがとうございます。
      たしかにデータベース修復したら~とありますね。

      アイルのサーバーはphpMyAdminでなくdbmanagerというのでデータベースを管理してるんですが
      ・databaseのバックアップ
      ・databaseのリストア
      というメニューがあります。バックアップをとってバックアップファイルからリストアという流れなのですが、
      こわいのはdbmanager上でみるとデータベースの日本語が見事に文字化けしているんです--;
      MODXとweb上の表示は問題なかったので、そのままにしていたのですが、ここにきてツケが周ってきた気分です。
      dbmanagerのページは文字コードEUCなのに、MODXのデータがUTF-8なのが原因なので、
      むりやりブラウザのエンコードをUTF-8にすると直りますが、今度はdbmanagerのメニューが全部化ける^^;
      この状態でバックアップのダンプファイルをリストアするのは、かなりこわいので、もうすこし考えます…。

        • 26012
        • 324 Posts
        min-oさん、返信が遅れてすみません。

        Quote from: min-o at Jan 23, 2009, 03:32 AM

        たしかにデータベース修復したら~とありますね。
        アイルのサーバーはphpMyAdminでなくdbmanagerというのでデータベースを管理してるんですが
        ・databaseのバックアップ
        ・databaseのリストア
        というメニューがあります。バックアップをとってバックアップファイルからリストアという流れなのですが、
        こわいのはdbmanager上でみるとデータベースの日本語が見事に文字化けしているんです--;
        MODXとweb上の表示は問題なかったので、そのままにしていたのですが、ここにきてツケが周ってきた気分です。
        dbmanagerのページは文字コードEUCなのに、MODXのデータがUTF-8なのが原因なので、
        むりやりブラウザのエンコードをUTF-8にすると直りますが、今度はdbmanagerのメニューが全部化ける^^;
        この状態でバックアップのダンプファイルをリストアするのは、かなりこわいので、もうすこし考えます…。

        もしかしたらmin-oさん少し勘違いしてるかもしれません。リペア(修復)リストア(復旧)は、
        言葉は似てますが全く異なる処理で、DBのテーブルの破損状態を検査して修復を試みる処理です。
        そですね~Windowsのディスクチェックとかご存知でしょうか。あんな感じの処理になります。

        dbmanagerというツールを使ったことはないのですが、下のページを見ると、SQLの発行はできるようなので、
        テーブルの破損状態を検査して修復することは可能なはずです。
          ・アイル(dbmanagerの解説) : http://home.isle.ne.jp/service/iclusta/function/dbmanager.html
          ・テーブルの破損状態を検査するSQL文 : CHECK TABLE `テーブル名`
          ・テーブルの破損状態を修復するSQL文 : REPAIR TABLE `テーブル名`

        次に、dbmanager=EUC and MySQL内のデータ=UTF-8 という組み合わせについてですが。

        dbmanagerがEUCで文字化けして表示されるために、バックアップ&リストアが怖いのはよく分かりますが、
        これはdbmanagerの問題であって、肝心のDB(MySQL)は、UTF-8でしっかり作られてるはずです。
        1600ページものページがMODxで長年文字化けなく運用されてきたことがそれを物語っています。

        MODxの「ツール」>「バックアップマネージャ」を使ったことはありますでしょうか?
        MODxはUTF-8でインストールされているので、DB(MySQL)とも相性がいいはずです。
        こいつを使ってバックアップを取る手があります。

        但し、今は「テーブルが破損しているかもしれない」、という予想で話が進んでるので、もしかしたら、MODxでの
        バックアップもエラーになる可能性があります。しかし、一つ言えるのは、もし今まで定期的にバックアップを
        取らずに運用されてきたのだとすると、それは大変危険なことです。勿論これからもサイトの運用は続けていかれる
        のでしょうから、DBのバックアップはいずれ必要になり、絶対に避けては通れないことだと思います。
        ですから、「ツケが周ってきた」 ではなく、「自分の環境を改善するチャンス」ぐらいに考えて、判断されてはいかがでしょう。
          • 19592
          • 56 Posts
          >sama55 さん
          こちらこそ返信が送れて申し訳ありません。23日から別の作業にかかっていたためmodxサイトのほうはいじっていませんでした。

          もしかしたらmin-oさん少し勘違いしてるかもしれません。リペア(修復)とリストア(復旧)は、
          言葉は似てますが全く異なる処理で、DBのテーブルの破損状態を検査して修復を試みる処理です。
          ありがとうございます。おもいっきり勘違いしてました。^^;

          文字化けについて
          dbmanagerでバックアップしたダンプファイルは、文字コードUTF-8で中をみるとちゃんとしていました。
          ただしdbmanager側で入る日本語はEUCなので、日本語部分は二つが混在している状態です。

          バックアップマネージャーでのバックアップは数ヶ月に1度位とっていますが
          今確認したところ、1/9のバックアップは874kbで、それまで徐々にデータ量が増えていたのですが、今日取ったバックアップでは241kbと減っていました。時期的にもこの辺りでテーブルのどこかが壊れた可能性が高そうです。

          dbmanagerというツールを使ったことはないのですが、下のページを見ると、SQLの発行はできるようなので、
          テーブルの破損状態を検査して修復することは可能なはずです。
            ・アイル(dbmanagerの解説) : http://home.isle.ne.jp/service/iclusta/function/dbmanager.html
            ・テーブルの破損状態を検査するSQL文 : CHECK TABLE `テーブル名`
            ・テーブルの破損状態を修復するSQL文 : REPAIR TABLE `テーブル名`
          今週いっぱいは作業時間がとれないのですが、来週辺りにやってみようとおもいます。
            • 26012
            • 324 Posts
            Quote from: min-o at Jan 28, 2009, 01:38 AM

            文字化けについて
            dbmanagerでバックアップしたダンプファイルは、文字コードUTF-8で中をみるとちゃんとしていました。
            ただしdbmanager側で入る日本語はEUCなので、日本語部分は二つが混在している状態です。
            そうでしたか。予想通りです。

            Quote from: min-o at Jan 28, 2009, 01:38 AM

            バックアップマネージャーでのバックアップは数ヶ月に1度位とっていますが
            今確認したところ、1/9のバックアップは874kbで、それまで徐々にデータ量が増えていたのですが、今日取ったバックアップでは241kbと減っていました。時期的にもこの辺りでテーブルのどこかが壊れた可能性が高そうです。
            バックアップマネージャー使われてたんですね。失礼しました。
            でも、この辺から活路が見出せそうですね。

            Quote from: min-o at Jan 28, 2009, 01:38 AM

            今週いっぱいは作業時間がとれないのですが、来週辺りにやってみようとおもいます。
            応援してます。 wink
              • 19592
              • 56 Posts
              少し間が開きましたが
               ・テーブルの破損状態を検査するSQL文 : CHECK TABLE `テーブル名`
              をやってみました。

              CHECK TABLE `modx_categories`
              と書いて、modx_active_usersやmodx_site_contentもチェックしてみたのですが
              いつも

              1 row

              と結果が表示されます。
              なんとなくこれは1行目しかチックしていないのかしら、とも思うのですが…どうゆう意味なんでしょうか…?

              http://mirror.hostfuss.com/mysql/doc/refman/5.1/ja/check-table.html
              のCHECK TABLE 構文を見たのですが、わかりませんでした…orz

              またアイルのdbmanagerのSQLの発行ページには
              また、時間のかかる処理を行った場合はブラウザーがタイムアウトエラーになる場合があります。
              巨大なテーブルへの全件呼び出しはできるだけ避けて、件数を確認するようにして下さい。
              例:
              select count(*) from テーブル名; (テーブル名には実際のテーブル名を指定して下さい)
              とあるのですが、modx_site_contentはともかくmodx_categoriesは24行しかないので、大きすぎてタイムアウトってことは無いと思うんですが…。

              質問ばかりですいませんがよろしくお願いします。
                • 26012
                • 324 Posts
                Quote from: min-o at Feb 03, 2009, 05:04 AM

                 ・テーブルの破損状態を検査するSQL文 : CHECK TABLE `テーブル名`
                をやってみました。
                CHECK TABLE `modx_categories`
                と書いて、modx_active_usersやmodx_site_contentもチェックしてみたのですが
                いつも

                1 row

                と結果が表示されます。
                なんとなくこれは1行目しかチックしていないのかしら、とも思うのですが…どうゆう意味なんでしょうか…?
                CHECK TABLE modx_xxxxxx ;
                と実行した場合に予想される表示は、以下のページのような感じになるはずなんですがね(phpMyAdminでもこうなります)。
                http://youkey.spaces.live.com/blog/cns!DF5ABB2B86ACBDDB!224.entry
                "1 row"という表示は、上のページの+-------------------+の一番下っぽいですね。 ("1 row in set (0.00 sec)")

                チェック結果が整形されて表示されてないだけなのかもしれませんが、なんとも・・・

                で、原因と対処は以下で。
                http://dev.mysql.com/doc/refman/4.1/ja/corrupted-myisam-tables.html


                Quote from: min-o at Feb 03, 2009, 05:04 AM

                またアイルのdbmanagerのSQLの発行ページには
                また、時間のかかる処理を行った場合はブラウザーがタイムアウトエラーになる場合があります。
                巨大なテーブルへの全件呼び出しはできるだけ避けて、件数を確認するようにして下さい。
                例:
                select count(*) from テーブル名; (テーブル名には実際のテーブル名を指定して下さい)
                とあるのですが、modx_site_contentはともかくmodx_categoriesは24行しかないので、大きすぎてタイムアウトってことは無いと思うんですが…。

                ちなみに、、以下の構文を入れるとどうなりますか?
                select count(*) from modx_site_content ;
                

                  • 19592
                  • 56 Posts
                  sama55 さん
                  返信ありがとうございます。
                  CHECK TABLE modx_xxxxxx ;
                  と実行した場合に予想される表示は、以下のページのような感じになるはずなんですがね(phpMyAdminでもこうなります)。
                  http://youkey.spaces.live.com/blog/cns!DF5ABB2B86ACBDDB!224.entry
                  "1 row"という表示は、上のページの+-------------------+の一番下っぽいですね。 ("1 row in set (0.00 sec)")

                  リンク先を見てみました。こうゆう風に出るものなんですね。
                  たしかに 1 row in set (0.00 sec) っぽいです…。

                  select count(*) from modx_site_content ;

                  を試してみましたら

                  count(*)
                  1344

                  とでました。行数はカウントしてるようです。
                  select count(*) from modx_categories;

                  では
                  count(*)
                  24
                  でした。

                  ちなみに
                  CHECK TABLE `****`の時は
                  CHECK
                  1 row
                  とでています。

                  こうゆう表示はdbmanagerの仕様なのかな…--;
                    • 26012
                    • 324 Posts
                    Quote from: min-o at Feb 03, 2009, 07:17 AM

                    こうゆう表示はdbmanagerの仕様なのかな…--;
                    CHECK TABLE modx_xxxxxx EXTENDED ;
                    では?
                      • 26012
                      • 324 Posts
                      あと、ここはSSHでログインできますか?
                      また、SSH(unixの一般的なコマンド[ls, pwd, cd とか])を使ったことありますか?
                      (dbmanagerというのが怪しげなので、シェルでDBに接続して、同様の操作を行うと、結果が違ったりして)

                      更に、DBのバックアップがあって復元可能であれば、REPAIR TABLE modx_xxxxx ;
                      を試してみるとか。

                      障害の原因がテーブルの破損と決まったわけではないので、はやいとこ、このポイントに
                      見切りを付けて、ダメならダメで、次へって行きたいですよね~。