업데이트 세트 충돌 해결
충돌은 최신 로컬 업데이트가 있는 업데이트입니다.
플랫폼은 각 업데이트 세트에서 고객 업데이트 기록의 이름 및 업데이트된 필드에 있는 값을 비교하여 충돌을 탐지합니다. 이름이 일치하지만 업데이트 날짜 값이 다른 경우 충돌이 발생한 것입니다.
고객 업데이트가 한 인스턴스에서 다른 인스턴스로 이동되면 대상 인스턴스와 일치하도록 다시 작성할 수 있습니다. 다시 쓰기에는 고객 업데이트의 업데이트 이름 및 업데이트 내 하나 이상의 sys_id 변경이 포함될 수 있습니다. 기록 또는 참조 필드가 병합 전략을 사용하는 테이블에 대한 것일 때 다시 쓰기가 수행됩니다. 이렇게 하면 고객 업데이트가 올바른 기록에 적용되는지 확인할 수 있습니다. 예를 들어, tablename.fieldname에 대한 sys_dictionary 기록이 인스턴스 A에서 123 sys_id고 인스턴스 B에서 sys_id 456 인 경우, 해당 기록을 참조하는 고객 업데이트가 인스턴스 A에서 검색되어 인스턴스 B의 sys_update_xml 테이블에 기록될 때 123 에 대한 참조는 456으로 업데이트됩니다.
병합 전략
병합은 업데이트 프로세스 중에 고유 식별자로 사용되는 하나 이상의 필드를 기반으로 기록을 식별하는 프로세스를 말합니다. 업데이트 세트는 개별 인스턴스에서 독립적으로 생성하는 동일한 기록 간의 충돌을 탐지할 수 있습니다. 이러한 충돌을 탐지하려면 기록에 병합 열을 기반으로 하는 병합 전략이 있어야 합니다. 충돌 탐지는 테이블의 고유성에 따라 달라지므로 병합 열을 결합할 때 테이블은 고유해야 합니다. 동일한 기록이 다른 인스턴스에서 별도로 생성되면 여기에 나열되지 않은 기록이 충돌하지 않습니다.
| 유형 | 열 병합 |
|---|---|
| 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_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 파일 익스포트 및 임포트를 참조하십시오.
- 시스템 사전에서 테이블에 대한 고유 인덱스를 사용하도록 설정합니다. 테이블 관리를 참조하십시오.