Udostępnij za pośrednictwem

OMPM 문제 'osWarning' 테이블의 'WarningInfo' 열 형식이 너무 작아서 데이터를 저장할 수 없습니다.' 해결 사례

  • Artykuł

최초 문서 게시일: 2011년 8월 25일 목요일

안녕하세요. Microsoft Consulting Services의 컨설턴트인 Anthony Cafarelli라고 합니다. 최근에 클라이언트 사이트에서 OMPM 검사를 수행하는 중에 몇 가지 유용한 정보를 확인할 수 있었습니다. 이에 이 블로그 게시물을통해 관련 정보를 알려 드리오니 유용하게 활용하시기 바랍니다.

이 블로그 게시물에서는 가져오기 오류에 대해 중점적으로 설명합니다. 이 오류는 검사하는 파일의 이름이 매우 긴 경우(250자 초과) 발생하므로 흔한 오류는 아니지만, 이러한 상황이 발생하는 경우 여기서 소개하는 단계를 수행하면 가져오기 문제를 해결할 수 있습니다. OMPM 데이터베이스로 데이터를 가져올 때 다음과 같은 오류가 표시될 수 있습니다.

'osWarning' 테이블의 'WarningInfo' 열 형식이 너무 작아서 데이터를 저장할 수 없습니다.'

이 오류는 가져오려는 XML 파일의 이름과 경로가 osWarning 테이블의 "Warninginfo" 필드에 대해 너무 길다는 의미입니다. 이러한 길이 문제로 인해 정보를 데이터베이스로 가져올 수 없으며, 해당 XML 파일은 건너뜁니다. 일반적으로 이 메시지는 마지막으로 액세스한 날짜 또는 마지막으로 수정한 날짜 경고와 함께 표시되므로, 보통 파일 자체가 데이터베이스에 있지 않은 것은 문제가 되지 않습니다. 그러나 오류의 원인이 되는 파일이 많은 XML 파일을 포함하는 .cab 파일에 들어 있는 경우에는 문제가 됩니다. offscan.ini 파일을 수정하여 설정을 변경한 경우가 아니면 CAB에는 1만 개 파일이 포함되므로, 해당 파일은 CAB에 포함될 가능성이 높습니다. 또한 CAB 파일에 포함된 XML 파일을 가져올 수 없으면 해당 파일을 모두 데이터베이스에 포함할 수 없습니다. 이 경우 다음과 같은 몇 가지 옵션 중에서 선택할 수 있습니다.

1)      가져오지 않은 CAB 파일은 무시하고 정상적으로 가져온 다른 CAB/XML 파일의 결과를 사용합니다.

2)      CAB 파일을 추출하여 각 XML을 가져옵니다.

3)      데이터베이스를 수정합니다.

옵션 1을 사용할 수 있는 경우에는 추가 설명이 필요하지 않겠죠. 이 옵션은 가장 간단한 옵션이지만 유용한 데이터가 많이 손실될 수 있습니다.

옵션 2는 숙고할 필요가 있습니다. 문제를 해결하기 위한 위의 두 가지 옵션(2번과 3번) 중에서 이 옵션을 사용하는 경우, 기술자가 많은 작업을 수행해야 하지만 데이터베이스로 파일을 가져오는 시간이 크게 줄어듭니다.

여기서 오류의 배경 정보를 간단하게 설명하겠습니다. XML 파일 하나에 오류가 있는데 전체 CAB를 가져올 수 없는 이유는 OMPM이 가져오기를 수행하는 방식 때문입니다. CAB는 가져오기 프로세스에서 추출되며 모든 XML 파일은 동시에 구문 분석됩니다. 따라서 CAB 파일 가져오기 속도가 크게 향상되지만, 오류를 해결할 수 있는 가능성은 그만큼 낮아집니다.

XML 파일을 추출하면 평균적으로 나머지 9,999개의 XML 파일은 데이터베이스로 가져올 수 있습니다. 실제로 시간을 재서 비교해 본 것은 아니지만, 개별 XML 파일을 가져오는 경우 속도가 최소 10배는 느려집니다. 가져오기 속도를 높이는 다른 방법이 있기는 하지만, 기술자가 더 많은 작업을 수행해야 합니다. 개인적으로는 지원 가능성 문제 때문에 데이터베이스를 수정하는 것을 원치 않으므로 이 방법을 선호하기는 합니다. 여기에 대해서는 뒷부분에서 좀 더 자세히 설명하겠습니다. 수정된 옵션 2는 다음과 같습니다.

1)      CAB 파일을 추출합니다.

2)      findstr 명령을 사용하여 추출된 XML 파일 중 오류가 있는 파일을 찾습니다.

3)      해당 XML 파일을 삭제합니다.

4)      나머지 파일로 다시 CAB 파일 패키지를 만듭니다.

이 방법을 사용하는 경우 빠른 가져오기 속도를 유지하면서 이름이 긴 파일 때문에 발생하는 오류를 해결할 수 있습니다. findstr을 사용하여 XML 파일을 삭제하는 작업은 간단하므로 여기서 설명하지 않겠습니다. 그러나 CAB 패키지를 다시 만드는 작업은 까다로울 수 있습니다. 개인적으로는 아래의 TechNet 페이지로 이동하여 해당 페이지에 나와 있는 PowerShell 스크립트를 구현하는 것이 가장 좋은 것 같습니다.

https://technet.microsoft.com/ko-kr/magazine/2009.04.heyscriptingguy.aspx(영문일 수 있음)

나머지 XML 파일을 다른 CAB 파일 패키지로 압축하고 나면 이전처럼 빠른 속도로 파일을 가져올 수 있으므로 매우 편리합니다.

다음으로 옵션 3에 대해 살펴보겠습니다. 이 옵션에 대해서는 상당히 복잡한 감정이 듭니다. 이 옵션은 간편하고 효율적이기는 하지만 지원 가능성이 떨어집니다. 이 방식에 대해 간단히 설명하자면, "데이터베이스의 oswarning 필드가 작아서 데이터를 모두 포함할 수 없기 때문에 필드 크기를 늘린다"는 의미입니다. 이렇게 하려면 다음과 같은 두 가지 방법을 사용할 수 있습니다. 또한 지금까지 작성한 스타일과 마찬가지로 이번에도 제가 선호하는 숫자가 지정된 목록으로 소개하겠습니다.

1)      SQL Management Studio를 사용하여 필드 크기를 수정합니다.

2)      OMPM에서 데이터베이스를 만드는 데 사용하는 파일을 수정하여 작성하는 모든 데이터베이스의 시작 필드 크기를 늘립니다.

SQL Management Studio 사용법 자체는 간단하지만, SQL 버전에 따라 사용법이 약간씩 달라질 수 있습니다. 여기서는 이 사용법에 대해 자세히 설명하지 않을 것이므로 사용법을 잘 모르면 선호하는 친구, 동료, 설명서, 블로그 등의 SQL 관련 리소스를 통해 사용법을 확인하거나 두 번째 방법을 사용하십시오. 

두 번째 방법에서는 텍스트 편집기를 사용합니다. 개인적으로 메모장을 즐겨 사용하므로 여기서도 예제로 메모장을 사용하겠습니다. 메모장을 시작하고 OMPM/Database/Include 폴더의 ProvisionDB.sql을 엽니다.

파일이 열리면 "oswarning"을 검색어로 입력하고 다음 찾기(Find Next)를 클릭합니다.

그러면 다음 항목이 표시됩니다.

보시다시피 WarningInfo 필드(255자)가 표시됩니다. 해당 값을 285 등의 더 큰 값으로 변경하면 됩니다. 그러면 createdb 명령을 실행할 때마다 새 데이터베이스에서 더 큰 필드가 사용됩니다. 참고로, 이 값을 변경해도 기존 데이터베이스는 수정되지 않으므로 새 데이터베이스를 만든 다음 해당 데이터베이스에서 가져오기를 실행해야 합니다. 이전 데이터베이스로 가져왔던 OMPMimported 폴더의 모든 파일을 새 데이터베이스로 다시 가져옵니다.

Office 호환성 팀에서는 이러한 제한을 파악하여 이후 업데이트에 반영하기 위해 관련 문제를 검토하고 있습니다.

이 게시물의 내용이 유용하셨나요? 다른 문제와 현장에서 확인한 "창의적인" 해결 방법에 대해 앞으로 블로그 게시물을 몇 개 더 작성할 예정입니다.

Anthony

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Experience from the Field: Resolving the OMPM issue “Type of column ‘WarningInfo’ in table ‘osWarning’ is too small to hold data”를 참조하십시오.