Практический опыт: разрешение проблемы OMPM "Тип столбца "WarningInfo" в таблице "osWarning" слишком мал, чтобы содержать данные"
Дата публикации исходной статьи: вторник, 25 августа 2011 г.
Меня зовут Энтони Кафарелли (Anthony Cafarelli), я являюсь консультантом в службе Microsoft Consulting Services и недавно подготовил список полезных советов, составленных мною при сканировании клиентских сайтов с использованием диспетчера планирования миграции Microsoft Office (OMPM). В этой записи блога мне хотелось бы поделиться некоторыми из полученных мною знаний. Я надеюсь, что они могут вам пригодиться!
Проблема, на которой я хочу остановиться в этой записи блога, связана с ошибкой импорта. Эта ошибка возникает, когда сканируемые файлы имеют очень длинные имена (больше 250 знаков). Это не слишком распространенная ошибка, но предлагаемые мною действия помогут вам все же выполнить импорт, если вы попадете в такую ситуацию. При импорте данных в базу данных OMPM может быть получено следующее сообщение об ошибке:
Тип столбца "WarningInfo" в таблице "osWarning" слишком мал, чтобы содержать данные
Эта ошибка указывает, что имя файла и путь к файлу XML, который вы пытаетесь импортировать, оказались слишком длинными для поля "Warninginfo" в таблице osWarning. Из-за этой проблемы необходимая информация не импортируется в базу данных и соответствующий файл XML пропускается. Обычно это сообщение отображается вместе с предупреждением о дате последнего доступа или последнего изменения, поэтому обычно не нужно опасаться, что соответствующего файла нет в базе данных. Однако бывает и другая ситуация, если он являлся частью CAB-файла, содержащего несколько файлов XML (а так, как правило, и бывает, и довольно часто CAB-файл содержит до 10 000 файлов, если только вы не изменили соответствующие параметры в файле offscan.ini). Поэтому важно отметить, что если какой-либо файл XML, содержащийся в CAB-файле, не может быть импортирован, то ни один из этих файлов не будет представлен в базе данных. В этом случае имеется несколько вариантов действий. Вы можете:
1) Игнорировать проблему, состоящую в том, что CAB-файл не был импортирован, и основывать свои результаты на других файлах формата CAB и XML, которые были импортированы правильно.
2) Извлечь CAB-файл и импортировать каждый файл XML по отдельности.
3) Изменить базу данных.
Если вариант 1 является для вас приемлемым, обсуждение на этом заканчивается. Это самый простой вариант, но при этом теряется большое количество данных, которые могли бы оказаться очень полезными.
Вариант 2 интересен. Из двух указанных выше вариантов решения проблемы этот вариант требует большой технической работы, при этом существенно возрастает время импорта в базу данных.
Если говорить коротко и упрощенно, то причина, по какой CAB-файл не может быть сразу целиком импортирован, если имеется ошибка всего в одном файле, связана со способом, который используется диспетчером планирования миграции Microsoft Office для выполнения импорта. CAB-файл извлекается в процессе импорта, и все файлы XML обрабатываются одновременно. Это значительно (ОЧЕНЬ значительно) ускоряет импорт CAB-файла, но также снижает и возможности для разрешения ошибок.
Если извлечь файлы XML, появится возможность импортировать (в среднем) 9 999 других файлов XML в базу данных. Я практически этого не делал и не сравнивал различные варианты, но могу сказать, что импорт индивидуальных файлов XML осуществляется по крайней мере в десятки раз, если не больше, медленнее. Имеется другой способ повысить скорость импорта, однако он подразумевает, что значительную работу должны проделать технические специалисты (я предпочитаю именно этот метод, поскольку я буквально ненавижу вносить изменения в базу данных, так как здесь возникают проблемы, связанные с вопросами поддержки, на чем я остановлюсь немного ниже). Модифицированный вариант 2 состоит в следующем:
1) Извлеките CAB-файл.
2) Используйте команду findstr, чтобы определить расположение извлеченного файла XML, содержащего ошибку.
3) Удалите этот файл XML.
4) Повторно упакуйте CAB-файл с оставшимися файлами.
При использовании этого метода сохранится высокая скорость импорта и решается проблема файла с длинным именем. Использование команды findstr и удаление файла XML особых комментариев не требует, поэтому останавливаться на этих операциях я не буду. Однако нахождение хорошего способа для выполнения повторной упаковки CAB-файла может оказаться сложной задачей. Лучшее, что я могу посоветовать в этой связи, перейдите на эту страницу (да, еще одна страница TechNet) и реализуйте скрипты PowerShell, представленные на ней:
https://technet.microsoft.com/en-us/magazine/2009.04.heyscriptingguy.aspx?pr=blog
После выполнения повторного сжатия для получения другого CAB-файла его можно импортировать, сохранив при этом высокую скорость импорта! Здорово, не так ли?
Поговорим теперь о варианте 3. Я испытываю по этому поводу довольно смешанные чувства. Используемый в нем подход является простым и эффективным, однако он наверняка приведет к проблемам с обеспечением поддержки. Простое объяснение данного подхода состоит в следующем: поле oswarning в базе данных является недостаточно большим, чтобы содержать данные, которые в него пытаются занести, поэтому данное поле нужно просто сделать достаточно большим. Я нашел 2 метода, с помощью которых это можно сделать. Из предыдущего изложения, думаю, понятно, что я испытываю симпатию к нумерованным спискам, поэтому привожу еще один:
1) Используйте SQL Management Studio для изменения размера поля.
2) Измените файлы, используемые диспетчером планирования миграции Microsoft Office для создания базы данных, поэтому каждая вновь создаваемая база данных будет иметь данное поле большего размера.
Работа со средой SQL Management Studio особых трудностей не представляет, однако в зависимости от версии SQL ее использование может иметь небольшие отличия. Я не буду подробно останавливаться на этом решении, поэтому, если вы с ним не очень знакомы, обратитесь за помощью к дополнительным источникам знаний по SQL (другу, коллеге, книге, блогу и т. п.) или же воспользуйтесь вторым методом.
Второй метод связан с использованием текстового редактора. Я предпочитаю Блокнот (Notepad.exe), поэтому воспользуюсь им в своем примере. Запустите Блокнот и откройте ProvisionDB.sql в папке OMPM/Database/Include.
После открытия этого файла найдите "oswarning" и щелкните "Найти далее" (Find Next).
Вы увидите следующее:
Здесь вы увидите поле WarningInfo (где указано: 255 знаков). Просто измените данное число на какое-нибудь большее значение (например, 285) и сохраните файл. Теперь при каждом запуске команды createdb в новой базе данных соответствующее поле будет больше. ПРИМЕЧАНИЕ. Это не приведет к изменению существующих баз данных, поэтому не забудьте создать новую базу данных и запустите импорт для нее. Если вы захотите "вытащить" из папки OMPMimported какие-либо файлы, импортированные в старую базу данных, повторите их импорт в новую базу данных.
Рабочая группа по совместимости Office Compatibility осведомлена об этом ограничении и рассматривает способы устранения этой проблемы в будущих обновлениях.
Надеюсь, приведенные здесь сведения окажутся полезными для кого-нибудь, кто прочел этот материал! Я собираюсь представить и некоторые другие записи блога, посвященные другими проблемам и их "креативным" решениям, найденным мною в процессе работы.
Энтони
Это локализованная запись блога. Исходная статья доступна по ссылке: Experience from the Field: Resolving the OMPM issue “Type of column ‘WarningInfo’ in table ‘osWarning’ is too small to hold data”