로컬 업데이트 세트 비교

  • 릴리스 버전: Zurich
  • 업데이트 날짜 2025년 07월 31일
  • 소요 시간: 7분
  • 관리자는 로컬 및 원격(검색된) 업데이트 세트를 미리 보고 세트를 서로 비교하여 상충하는 변경 내용을 해결할 수 있습니다.

    시작하기 전에

    필요한 역할: admin.

    이 태스크 정보

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

    프로시저

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

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

    5. 별도의 업데이트 세트에서 동일한 변경을 보여주는 중복 충돌 번호 를 찾아 목록에서 충돌을 검사합니다.
      그림 2. 업데이트 세트 충돌
      업데이트 세트 충돌
    6. 업데이트 세트 중 하나에서 원치 않는 업데이트 기록을 삭제하여 충돌을 해결합니다.
      1. Sys update 열에서 원치 않는 업데이트의 링크를 클릭합니다(예시에서 sys_ui_list_incident_null).
      2. 삭제를 클릭합니다.
        주:
        기록을 삭제하려면 업데이트 기록을 열어야 합니다. 업데이트 세트 충돌 목록에서 항목의 확인란을 선택하고 삭제 작업을 사용하여 업데이트를 삭제할 수 없습니다. 업데이트 기록을 삭제하면 인스턴스에서 사용자 지정이 원상복구되지 않습니다. 커스터마이제이션 기록만 삭제됩니다.
        그림 3. 고객 업데이트
        고객 업데이트
    7. 비교를 다시 실행하여 모든 충돌이 해결되었는지 확인합니다.

    업데이트 세트 충돌 해결

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

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

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

    병합 전략

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

    유형 열 병합
    atf_input_variable 이름, 요소
    atf_output_variable 이름, 요소
    dp_data_pattern source_sys_id
    dynamic_attribute namespaced_name
    dynamic_category namespaced_name
    dynamic_category_member 범주, 속성
    dynamic_choice_override 선택, 범주, 속성
    dynamic_namespace 이름
    sys_analytics_bucket sys_scope, bucket_document_id, bucket_table_name
    sys_attachment (사용자 지정 일치 논리 사용)
    sys_choice_set 이름, 요소
    sys_collection 컬렉션, 이름, join_field
    sys_db_object 이름
    sys_df_data_dictionary 이름, 요소
    sys_dictionary 이름, 요소
    sys_documentation 이름, 요소, 언어
    sys_index logical_table_name, col_name_string
    sys_module 경로
    sys_notification_category 이름
    sys_package 소스
    sys_package_dependency_m2m 종속성, sys_package
    sys_properties 이름
    sys_report_chart_color 이름, 요소, 값
    sys_scope_script_access source_scope, target_scope, script_name
    sys_scope_table_access source_scope, target_scope, table_name
    sys_script_validator internal_type, ui_type
    sys_translated 이름, 요소, 값, 언어
    sys_translated_text tablename, fieldname, documentkey, language
    sys_ui_form 이름, 보기, sys_domain
    sys_ui_list 이름, 보기, sys_domain, 요소, 관계, 상위
    sys_ui_message 키, 언어, 코드
    sys_ui_related_list 이름, 보기, related_list, sys_domain
    sys_ui_section 이름, 보기, 캡션, sys_domain
    sys_ui_view 이름
    sys_user_group 이름
    sys_user_role 이름
    sys_wizard 이름
    ua_table_licensing_config 이름

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

    병합을 이해하려면 병합되지 않는 기록의 작동 방식을 이해하는 것이 도움이 됩니다. 대부분의 기록 유형에서 고객 업데이트가 새 인스턴스로 이동되면 시스템은 다음과 같은 이유로 충돌을 탐지하지 못합니다.
    • 기록을 만들면 고유한 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에는 "123456789"sys_id 있고 인스턴스 B에는 "987654321"sys_id 있는 경우, 해당 기록을 참조하는 고객 업데이트가 인스턴스 A에서 검색되어 인스턴스 B의 sys_update_xml 테이블에 기록되면 "123456789"에 대한 참조가 "987654321"로 업데이트됩니다.

    중복 기록 방지

    • 데이터를 별도의 인스턴스에서 다시 생성하지 않고 업데이트 세트로 전송하여 기록의 sys_id 동일하도록 합니다.
    • 기록을 XML 파일로 익스포트하고 임포트하여 기록의 sys_id이 동일한지 확인합니다. XML 파일 익스포트 및 임포트를 참조하십시오.
    • 시스템 사전에서 테이블에 대한 고유 인덱스를 사용하도록 설정합니다. 테이블 관리를 참조하십시오.
    주:
    인스턴스가 인스턴스 프로비저닝 중에 기록을 XML 파일로 임포트하기 때문에 베이스라인 시스템에 포함된 기본 기록은 항상 동일한 시스템 ID를 갖습니다.