絞り込み条件を変更する
検索条件を絞り込む

すべてのカテゴリ

3 件中 1 - 3 件表示
カバー画像

「データベースが開けません」と出たとき — 何%戻るかを言い切る人は、たぶん見ていません

長年使ってきたソフトを開いたら、起動しない。エラーの文言をそのまま検索すると、データベースが壊れているらしい。そんな状況になったことはありませんか。・業務で使っているアプリが起動せず、データが読めなくなった・`database disk image is malformed` のようなメッセージが出る・バックアップはあるが、半年前のもので、そこから今までの入力が入っていないまず、いちばん急ぐことをお伝えします。何よりも先に、コピーを取ってくださいそのファイルに、これ以上さわらないでください。やることは1つだけです。壊れたファイルを、別の場所へコピーする。それだけです。USBメモリでも、別のフォルダでも構いません。できれば2か所に置いてください。理由は単純で、復旧を試みる操作そのものが、状態をさらに悪くすることがあるからです。修復ツールを走らせる、アプリで開き直す、再インストールする。どれも、残っている断片を上書きしてしまう可能性があります。元のファイルさえ手つかずで残っていれば、何度でもやり直せます。復旧で最初にやるべきことは、直すことではなく壊れた状態を保存することです。「何%戻りますか」に答えられる人はいません次に聞きたくなるのが、これです。ですが、この質問に事前に答えられる人はいません。データベースが壊れるといっても、壊れ方はさまざまです。先頭の数十バイトだけが書き換わったのなら、中身はほぼ無傷です。ファイルの後ろ半分が切り落とされていたら、その部分は誰にも取り戻せません。消えたバイトは、どんな技術でも復元できません。そして、どちらの壊れ方なのかは、開いてみるまで分かりま
0
カバー画像

業務システムの不具合調査で最初に確認すべき5つの情報

業務システムで「保存できない」「計算結果が合わない」「特定の画面だけエラーになる」といった問題が起きると、すぐに修正箇所を探したくなります。しかし実務では、原因が見えないまま修正に入るほど、影響範囲の見落としや別不具合につながりやすくなります。最初に大切なのは、直すことではなく、何が、どの条件で、どこまで起きているのかを整理することです。問題が長引く理由の多くは、情報が断片的なまま共有されることにあります。「エラーが出る」という一言だけでは、入力値の問題なのか、権限なのか、データの状態なのか、プログラムの分岐なのか判断できません。業務システムは、画面、処理ロジック、データベース、外部ファイル、利用者権限がつながって動くため、画面だけを見ても原因がわからないことがあります。最初に確認したい情報は5つあります。1つ目はエラーメッセージです。文言だけでなく、発生時刻、画面名、操作内容も残します。2つ目は再現手順です。どの画面を開き、どの項目に何を入力し、どのボタンを押したかを順番に書きます。3つ目は発生条件です。特定の利用者だけか、特定の日付や区分だけか、同じ操作でも成功する場合があるかを確認します。4つ目は正常時との違いです。過去に成功したデータ、別の利用者、別の月度などと比較すると差分が見えます。5つ目はログ、ソースコード、DBデータです。ここで画面の現象と内部処理を突き合わせます。対応手順としては、まず現象を1枚にまとめ、再現できるかを確認します。次に正常データと異常データを比較し、入力値、権限、マスタ、履歴データの違いを見ます。そのうえでログの時刻と処理の流れを合わせ、該当す
0
カバー画像

マルウェアを疑ったけど違った:WordPressの重さを生んだ“隠れリクエスト”の原因特定手順

はじめに:症状は「重い」と「アクセスが増えたように見える」あるWordPressサイトが、ある時期から急に重くなりました。体感だけでなく、計測でもページ表示に数秒〜十数秒かかることが増え、同時にアクセス解析(あるいは負荷ランキング)の数字が「不自然に増える」ように見えるようになりました。具体的には、スマホで同じページを**1回更新しただけなのに、ヒット数が+1ではなく+13〜+14**のように増えてしまう現象が起きました。  最初は「ボット?」「マルウェア?」「不正アクセス?」と疑いましたが、結論はまったく違うところにありました。---まずやったこと:1回の更新で“何本リクエストが発生しているか”を見える化するWordPressが重いとき、原因の切り分けでまず重要なのはこれです。> **「ブラウザが1回のページ表示で、実際に何本HTTPリクエストを追加で出しているか」**管理画面側に、簡易的な「リクエスト負荷ランキング/トレース」的な仕組み(記録テーブル+表示画面)を用意して、以下の手順で確認しました。1. 記録ログを全削除  2. スマホで対象ページを**1回だけ**更新  3. 記録されたリクエスト一覧を、**Referer(参照元URL)**で絞り込み  4. `/wp-json/...` や `/admin-ajax.php` が何本出ているかを数えるこの時点で、“1回更新で+13〜+14” という体感の正体が見え始めました。---判明したこと:ページ表示の裏で REST API が十数回呼ばれていたログを見て分かったのは、単にページHTMLを1回取りに行っている
0
3 件中 1 - 3