로컬 업데이트 세트 비교

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

이 태스크 정보

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

프로시저

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에 sys_id 123456789이고 인스턴스 B에 987654321 sys_id 경우 해당 레코드를 참조하는 고객 업데이트가 인스턴스 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

결과적으로, 기록이 동일하더라도 기록 이름이 다르기 때문에 시스템이 충돌을 감지하지 못합니다.

반면, 병합 레코드는 다음과 같은 접근 방식을 사용하여 레코드의 이름을 지정하고 충돌을 확인합니다. 다음 고객 업데이트 레코드 종류는 이름에 있는 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 sys_id "123456789"이고 인스턴스 B sys_id "987654321"인 경우 해당 레코드를 참조하는 고객 업데이트가 인스턴스 A에서 검색되고 인스턴스 B의 sys_update_xml 테이블에 기록되면 "123456789"에 대한 참조가 "987654321"로 업데이트됩니다.

중복 기록 방지

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

주:

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