로컬 업데이트 세트 비교

관리자는 로컬 및 원격(검색된 업데이트) 업데이트 세트를 미리 보고 서로 비교하여 상충하는 변경 사항을 해결할 수 있습니다.

이 태스크 정보

로컬 업데이트 세트를 비교하여 충돌을 식별하고 적절한 변경 사항이 커밋되고 있는지 확인합니다. 인스턴스 간에 업데이트 세트를 이동하기 전에 모든 상충을 해결합니다.

프로시저

1. 다음으로 이동 모두 > 시스템 업데이트 세트 > 로컬 업데이트 세트.
2. 비교할 업데이트 세트 옆에 있는 확인란을 선택합니다.
3. 작업 선택 목록에서 업데이트 세트 비교를 선택합니다.
   충돌 보고서를 생성할 때 ServiceNow 진행률 화면이 나타납니다.

   그림 1. 충돌 보고서

   

4. 보고서가 완료되면 충돌 보고서로 이동을 클릭합니다.

   업데이트 세트 충돌 목록이 나타나고 선택한 세트의 모든 변경 사항이 표시됩니다.

5. 별도의 업데이트 세트에서 동일한 변경을 보여주는 중복 충돌 번호를 찾아 목록의 충돌을 검사합니다.

   그림 2. 업데이트 세트 충돌

   

6. 업데이트 세트 중 하나에서 원치 않는 업데이트 기록을 삭제하여 충돌을 해결합니다.
   1. 원치 않는 업데이트(예의 sys_ui_list_incident_null)에 대한 Sys update(시스템 업데이트) 열의 링크를 클릭합니다.
   2. 삭제를 클릭합니다.
      주:

      기록을 삭제하려면 업데이트 기록을 열어야 합니다. 업데이트 세트 충돌 목록의 항목에 대한 확인란을 선택하고 삭제 작업을 사용하여 업데이트를 삭제할 수 없습니다. 업데이트 기록을 삭제해도 커스터마이제이션이 인스턴스에서 원상 복구되지 않습니다. 커스터마이제이션의 기록만 삭제됩니다.

      그림 3. 고객 업데이트

      

7. 비교를 다시 실행하여 모든 충돌이 해결되었는지 확인합니다.

업데이트 세트 충돌 해결

충돌은 최신 로컬 업데이트가 있는 업데이트입니다.

플랫폼은 각 업데이트 세트의 고객 업데이트 기록에 있는 이름 및 업데이트됨 필드의 값을 비교하여 충돌을 탐지합니다. 이름이 일치하지만 업데이트 날짜 값이 다른 경우 충돌이 발생합니다.

고객 업데이트가 한 인스턴스에서 다른 인스턴스로 이동될 때 대상 인스턴스와 일치하도록 다시 작성할 수 있습니다. 다시 쓰기에는 고객 업데이트의 업데이트 이름 및 업데이트 내의 하나 이상의 sys_id변경이 포함될 수 있습니다. 기록 또는 참조 필드가 병합 전략을 사용하는 테이블에 대한 경우 다시 쓰기가 수행됩니다. 이렇게 하면 고객 업데이트가 올바른 기록에 적용됩니다. 예를 들어, tablename.fieldname에 대한 sys_dictionary 기록이 인스턴스 A에 123456789sys_id 있고 인스턴스 B에 sys_id 987654321 있는 경우, 해당 기록을 참조하는 고객 업데이트가 인스턴스 A에서 검색되어 인스턴스 B의 sys_update_xml 테이블에 기록되면 123456789에 대한 참조가 987654321 읽도록 업데이트됩니다.

병합 전략

업데이트 세트는 별도의 인스턴스에서 독립적으로 생성하는 동일한 기록 간의 충돌을 감지할 수 있습니다. 이러한 충돌을 탐지하려면 기록에 병합 열을 기반으로 하는 병합 전략이 있어야 합니다. 충돌 탐지는 테이블의 고유성에 따라 달라지므로 병합 열이 결합될 때 테이블이 고유해야 합니다. 여기에 나열되지 않은 기록은 동일한 기록이 서로 다른 인스턴스에서 별도로 생성되는 경우 충돌하지 않습니다.

유형	병합 열
sys_db_object	이름
sys_dictionary	이름, 요소
sys_choice_set	이름, 요소, 언어
sys_documentation	이름, 요소, 언어
sys_properties	이름
sys_report_chart_color	이름, 요소, 값
sys_ui_form	이름, 뷰, sys_domain
sys_ui_message	documentkey, 언어
sys_ui_list	이름, 뷰, sys_domain, 요소, 관계, 상위
sys_ui_section	이름, 뷰, 캡션 sys_domain
sys_ui_related_list	이름, 뷰, related_list, sys_domain
sys_ui_view	이름
sys_user_role	이름
sys_user_group	이름
sys_wizard	이름

고객 업데이트 기록 이름이 충돌에 미치는 영향

병합을 이해하려면 병합되지 않는 기록의 작동 방식을 이해하는 것이 도움이 됩니다. 대부분의 기록 유형에서 고객 업데이트가 새 인스턴스로 이동되면 시스템은 다음과 같은 이유로 충돌을 감지하지 않습니다.

• 기록을 만들면 고유한 sys_id 수신됩니다. 대부분의 기록 유형에서 sys_id는 고객 업데이트 기록 이름의 일부가 됩니다. 예: sysevent_email_template_9e1998c078b71100a92ecacd80df1d39.
• 다른 인스턴스의 동일한 테이블에서 동일한 기록을 만들면 다른 sys_id 가진 고객 업데이트 기록 이름이 생성됩니다. 예: sysevent_email_template_10b958c8653311005840134572f8e020

따라서 기록이 동일하더라도 기록의 이름이 다르기 때문에 시스템이 충돌을 감지하지 못합니다.

반대로 기록 병합은 다음과 같은 접근 방식을 사용하여 기록에 이름을 지정하고 충돌을 결정합니다. 다음 Customer Update 기록 유형은 이름에 sys_id 대신 병합 열의 일부 또는 전부를 사용합니다.

• sys_dictionary
• sys_documentation
• sys_choice_set
• sys_ui_list
• sys_ui_related_list

결과적으로 각 인스턴스에서 동일한 레코드 이름을 사용하면 레코드 sys_ids 다르더라도 시스템에서 충돌을 식별하는 데 도움이 됩니다.

고객 업데이트가 한 인스턴스에서 다른 인스턴스로 이동될 때 대상 인스턴스와 일치하도록 다시 작성할 수 있습니다. 다시 쓰기에는 고객 업데이트의 업데이트 이름 및 업데이트 내의 하나 이상의 sys_ids 변경이 포함될 수 있습니다. 기록 또는 참조 필드가 병합 전략을 사용하는 테이블에 대한 경우 다시 쓰기가 수행됩니다. 이렇게 하면 고객 업데이트가 올바른 기록에 적용됩니다. 예를 들어, tablename.fieldname에 대한 sys_dictionary 기록이 인스턴스 A에서 "123456789"sys_id 있고 인스턴스 B에서 "987654321"sys_id 있는 경우, 해당 기록을 참조하는 고객 업데이트가 인스턴스 A에서 검색되어 인스턴스 B의 sys_update_xml 테이블에 기록될 때 "123456789"에 대한 참조는 "987654321"로 업데이트됩니다.

중복 기록 방지

• 별도의 인스턴스에서 데이터를 다시 생성하지 않고 업데이트 세트로 데이터를 전송하여 기록의 sys_id 동일하게 유지하십시오.
• 기록이 동일한 sys_id 갖도록 기록을 XML 파일로 익스포트하고 임포트합니다. XML 파일 내보내기 및 가져오기를 참조하십시오.
• 시스템 딕셔너리에서 테이블에 대해 고유 인덱스를 사용하도록 설정합니다. 테이블 관리 섹션을 참조하십시오.

주:

인스턴스가 인스턴스를 프로비저닝하는 동안 기록을 XML 파일로 임포트하기 때문에 베이스라인 시스템에 포함된 기본 기록은 항상 동일한 시스템 ID를 갖습니다.