現場からの声: “テーブル‘osWarning’ の列の型 ‘WarningInfo’ は小さすぎてデータを保持できません” という OMPM 問題を解決する
原文の記事の投稿日: 2011 年 8 月 25 日 (木曜日)
Anthony Cafarelli です。近頃、私は Microsoft Consulting Services のコンサルタントとしてお客様の現場で OMPM スキャンを実行しながら得た役立つアドバイスの一覧をまとめました。このブログ投稿では、その知識の一部を分かち合いあいたいと思います。これは役立つと思っていただければ幸いです。
このブログ投稿で焦点を置いている問題は重要なエラーです。このエラーは、スキャンしたファイルの名前が非常に長い (250 文字を超える) と引き起こされます。したがって、非常によくある問題というわけではありませんが、次の手順を使用すれば、この状況に気付いたときにインポートに対処できます。データを OMPM データベースにインポートすると、次のエラー メッセージが出力されることがあります。
テーブル‘osWarning’ の列の型 ‘WarningInfo’ は小さすぎてデータを保持できません。
このエラーの意味は、インポート対象の XML ファイルのファイル名およびパスが osWarning テーブルの “Warninginfo” フィールドには長すぎる、ということです。この長さの問題のため、データはデータベースにインポートされず、その XML ファイルはスキップされます。一般に、このエラー メッセージは最終アクセス日または最終変更日の警告と一緒に表示されるので、通常はファイルがデータベース内にないという問題ではなりません。しかし、このファイルが複数の XML ファイルを含む .cab ファイルの一部だとしたらどうでしょうか (その可能性は高く、offscan.ini ファイルを変更してこれらの設定を変更していない限り、おそらく CAB には 10,000 個のファイルが含まれています)。これは、CAB ファイルに含まれているいずれかの XML ファイルをインポートできなければ、それらのファイルはいずれもデータベースに入らないという注意すべき重要なことです。この時点での選択肢は、次のとおりです。
1) CAB ファイルがインポートされなかったことを無視し、正常にインポートされたその他の CAB/XML ファイルに結果を託す。
2) CAB ファイルを展開して、各 XML をインポートする。
3) データベースを変更する。
選択肢 1 が受け入れ可能な場合は、ここで私が説明することはもうありません。最も簡単な選択肢ですが、役立つ可能性がある大量のデータを失います。
選択肢 2 は興味深い選択肢です。問題に対処するこれらの 2 つの選択肢のうち、これは技術スタッフの代わりに多くの作業が必要になる選択肢ですが、データベースにインポートするための時間が著しく増加します。
簡単に背景を少し紹介しましょう。1 つの XML ファイルでエラーが発生しただけで CAB 全体がインポートされない理由は OMPM がインポートを実行する方法にあります。CAB はインポート プロセスで展開されて、すべての XML ファイルが一度に解析されます。これにより、CAB ファイルのインポートの時間は大幅に (非常に大幅に) 短縮されますが、エラーに対処できるチャンスも減ります。
XML ファイルを抽出する場合は、データベースにインポートされたその他の (平均で) 9,999 個の XML ファイルを取得できます。実際にその時間を測定したことも、比較したこともありませんが、XML ファイルを個別にインポートすると、少なくとも 10 倍は遅くなるようです。インポート速度を向上する方法はもう 1 つありますが、この方法では技術スタッフの作業が増えます (また、これが私のお気に入りの方法なのは、サポート問題の理由からデータベースを変更したくないためです。この点については、後で少し説明します)。 次に、変更を加えた選択肢 2 について説明します。
1) CAB ファイルを展開します。
2) findstr コマンドを使用して、エラーが発生したファイルである、抽出された XML ファイルを見つけます。
3) その XML ファイルを削除します。
4) 残りのファイルで CAB ファイルを再パッケージします。
この方法を使用すれば、高速のインポートを維持し、長い名前を持つファイルに対処できます。findstr を使用して XML ファイルを削除する方法は非常に簡単なので、ここでは説明しません。ただし、CAB を再パッケージするための便利な方法を見つけるのは大変かもしれません。個人的には、次のページにアクセスして (別の TechNet ページです)、そこに示されている PowerShell スクリプトを実装することをお勧めします。
https://technet.microsoft.com/ja-jp/magazine/2009.04.heyscriptingguy.aspx
別の CAB ファイルに再圧縮し終えたら、それをインポートして、高速インポートを維持できます。かなり便利な方法でしょう。
では、選択肢 3 について説明しましょう。この選択肢についてはかなり複雑な気持ちです。簡単で、効果的ではありますが、間違いなくサポートが強く求められます。この方法を簡単に説明すると、データベースの oswarning フィールドはそこに入れるデータを保持できるほど大きくないので、バケットを大きくしましょう、ということです。私は、この処理を行う方法を 2 つ見つけました。そして、どうやら、これまで書いてきたものによると、私は番号付きのリストが好きなので、ここでも同じようにします。
1) SQL Management Studio を使用してフィールド サイズを変更します。
2) 作成する各データベースのフィールド サイズが最初から大きくなるように、OMPM がデータベースの作成に使用するファイルを変更します。
SQL Management Studio の使用は比較的簡単ですが、お使いの SQL のバージョンに応じて、若干異なることがあります。ここでは、そのソリューションについては詳しく説明しませんので、よくわからない場合は、お気に入りの SQL リソース (友人、同僚、書籍、ブログなど) を見つけて調べるか、2 番目の方法を使用してください。
2 番目の方法では、テキスト エディターを起動する必要があります。notepad.exe が私のお気に入りなので、ここではサンプルとしてこれを使用します。メモ帳を開始し、OMPM/Database/Include フォルダーにある ProvisionDB.sql を開きます。
ファイルが開いたら、“oswarning” を検索し、[次を検索](Find Next) をクリックします。
次のように表示されます。
WarningInfo フィールドが (255 文字で) 表示されます。この数字を単にもっと大きい値 (たとえば、285) に変更して、ファイルを保存するだけです。createdb コマンドを実行するたびに、新しいデータベースのフィールド サイズは大きくなります。注: この方法では、既存のデータベースは変更されません。必ず新しいデータベースを作成し、そこでインポートを実行してください。古いデータベースにインポートした OMPMimported フォルダーからファイルを抜き出せば、それらのファイルを新しいデータベースに再インポートできます。
Office Compatibility チームではこの制限を認識しています。将来的な更新プログラムでこの問題点を見直します。
このブログが皆様のお役に立てば幸いです。この分野で私が見つけたその他の問題点と “独創的な” 解決策を今後もいくつかのブログで執筆する予定です。
Anthony
これはローカライズされたブログ投稿です。原文の記事は、「Experience from the Field: Resolving the OMPM issue “Type of column ‘WarningInfo’ in table ‘osWarning’ is too small to hold data”」をご覧ください。