SAP BOX

'26/11/14 UPDATE

BASIS / FIELD NOTES

S/4HANA 업그레이드가 끝났는데, 데이터 이전도 다 끝난 걸까

SUM이 끝나도 S/4HANA의 데이터 이전(SDMI)은 시스템을 쓰는 동안(업타임) 클라이언트마다 계속 돌고, 기술 사용자가 없는 클라이언트에서는 시작조차 하지 않습니다. SDM_USER·SM37·SDM_MON에서 무엇을 어떤 순서로 보고 어느 상태여야 끝났다고 할 수 있는지, 릴리스를 건너뛸 때 무엇이 달라지는지 정리합니다.

SUM(Software Update Manager)이 마지막 단계를 마치고 시스템이 업무에 돌아오면 업그레이드는 끝난 것처럼 보입니다. 그런데 S/4HANA에서는 그 뒤에도 데이터 이전이 시스템을 쓰는 동안(업타임) 클라이언트마다 따로 돕니다. 이 글을 읽고 나면 그 이전(SDMI)이 모든 클라이언트에서 끝났는지 SDM_USER, SM37, SDM_MON 세 화면으로 차례대로 확인하고, 어느 상태여야 끝났다고 적을 수 있는지 알 수 있습니다.

근거는 ABAP Platform 2025 FPS02의 SDMI 도움말(영어), SAP S/4HANA 2025 전환 가이드(문서판 3.0), SUM 2.0 SP27 가이드이고 2026년 10월 27일에 확인했습니다. 실제 시스템에서 실행하지는 않았고, 클라이언트 200과 사용자 ZSDM_TECH는 가상 값입니다. 로그인이 필요한 SAP Note는 번호와 공개 제목만 보고 적었고, 본문은 읽지 않았습니다.

SUM이 끝난 뒤에 도는 데이터 이전

릴리스를 올리면 데이터 구조가 바뀌어 옛 구조의 데이터를 새 구조로 옮겨야 하는 일이 많습니다. 이런 이전은 보통 시스템을 멈춘 다운타임에 합니다. SDMI(Silent Data Migration Infrastructure)는 SAP HANA 테이블의 애플리케이션 데이터를 자동으로 옮기는 프레임워크입니다. 이 프레임워크로 구현된 이전은 다운타임이 아니라 업그레이드나 전환 뒤, 시스템을 쓰는 동안 돕니다.

기본은 업타임 실행입니다. 시스템이 유지보수 모드에서 나오면 잡 저장소(job repository)의 잡이 시작되어 클라이언트마다 따로 SDMI를 부릅니다. SUM이 끝난 순간에는 이전이 막 시작됐을 수 있습니다. 이전은 모든 클라이언트에서 모든 SDMI가 성공해야 끝납니다. 그 전까지 업그레이드는 끝나지 않은 채로 남고, 목표 릴리스의 새 기능 일부를 쓰지 못할 수 있으며, 다음 업그레이드도 시작할 수 없습니다.

클라이언트마다 기술 사용자가 있어야 시작된다

애플리케이션 데이터는 대개 클라이언트에 묶여 있어서, SDMI는 클라이언트마다 그 클라이언트의 기술 사용자로 배치 잡을 돌립니다. 이 사용자는 시스템 사용자(유형 B)이고 SAP_ALL 프로필을 가져야 합니다. 만드는 길은 두 가지입니다. 하나는 SUM이 업그레이드 중에 띄우는 대화창입니다. YES를 고르면 사용자가 없는 클라이언트마다 SUM이 만들고, NO를 고르면 만들지 않습니다. 사후 처리 단계에서는 SUM이 기술 사용자가 있는지 확인하고, 없으면 업데이트 로그에 P 메시지를 남깁니다.

다른 하나는 트랜잭션 SDM_USER(SDMI User Monitor)입니다. 사용자가 빠진 클라이언트에 로그온해 Create/Change를 누르고, 대화창에 사용자 이름을 넣거나 Generate User로 임의 이름을 만든 뒤 Next를 누릅니다. 사용자는 로그온한 클라이언트에만 만들어져 SDMI 사용자 테이블에 들어갑니다. 이미 기술 사용자가 있으면 F4로 고릅니다. SUM 전에 미리 만들면 사내 이름 규칙에 맞출 수 있고, SUM 뒤에 만들어도 됩니다. SDMI에 필요한 권한은 제목으로 보아 SAP Note 2850918이 다룹니다.

SAP GUI SDM_USER SDMI User Monitor 화면 예시. 응용 도구 모음에 Create/Change 버튼이 있고, SDMI User 대화창의 Username 칸에 가상 사용자 ZSDM_TECH가 들어 있어 번호 1, Generate User에 번호 2, Next에 번호 3이 붙어 있다. 설명: 사용자는 유형 B 시스템 사용자에 SAP_ALL 프로필이어야 하고 이미 있으면 F4로 고른다. 임의 이름 사용자의 잡도 SM37에서 사용자 이름 *로 찾으면 나온다. 사용자는 로그온한 가상 클라이언트 200에만 만들어지고 다른 클라이언트에서는 따로 만든다.
SDM_USER에서 Create/Change를 눌러 연 대화창 예시. 대화창 제목과 배치는 설명용이고, 클라이언트 200과 사용자 이름은 가상이다.

사용자가 없는 클라이언트에서는 SDMI가 시작되지 않고 데이터도 옮겨지지 않습니다. 앞의 P 메시지 말고는 따로 알려 주는 것이 없고, 그 사실은 시스템 로그(SM21)에만 남습니다. 시스템 로그는 크기가 정해져 있어 오래된 메시지가 덮어써질 수 있고, SM21은 기본으로 로컬 인스턴스의 최근 두 시간만 보여 줍니다. 그래서 클라이언트마다 SDM_USER의 Create/Change 대화창을 열어, 기술 사용자가 이미 있으면 F4로 고르고 없으면 만드는 편이 확실합니다. SUM의 P 메시지 목록은 CHK_POSTUP 단계의 longpost.log에 모이지만, 이 확인이 어떤 문구로 남는지는 공개 문서로 확인하지 못했습니다.

먼저 SM37에서 잡을 본다

점검은 잡 예약을 먼저 보고 그다음 이전 상태를 봅니다. 전제는 AS ABAP 7.54 이상이고, 7.54는 S/4HANA 1909에 해당합니다. SM37의 잡 선택 화면에서 Job Name에 SAP_SDM_EXECUTOR_ONLINE_MIGR를, User Name에 *를 넣습니다. 그래야 모든 SDM 잡이 나오고, Generate User로 만든 낯선 이름의 사용자 잡도 나옵니다. 잡 상태는 기본 선택을 그대로 둡니다. SDM 잡은 30분마다 돌기 때문에 시작 조건도 바꿀 필요가 없습니다. Execute를 누르면 모든 클라이언트의 SDM 잡과 상태가 나옵니다.

SAP GUI SM37 Simple Job Selection 화면 예시. Job Name 칸에 SAP_SDM_EXECUTOR_ONLINE_MIGR가 들어 있어 번호 1, User Name 칸의 *에 번호 2가 붙어 있다. Job Status 묶음에 Planned, Released, Ready, Active, Finished, Canceled가 체크되어 있고 Canceled에 번호 3이 붙어 있다. 설명: 잡은 30분마다 돌아 시작 조건을 바꾸지 않고, 모든 클라이언트의 잡을 보려면 배치 관리자 권한이 필요하며, 상태는 기본 선택을 두고 Canceled 잡은 Goto > Job Log로 원인을 본다.
SM37 잡 선택 화면에 SDM 잡 이름과 사용자 *를 넣은 예시. 잡 이름은 SAP 문서에 나오는 실제 이름이고, 화면 글자와 체크 표시는 설명용이다.

'모든 클라이언트'에는 조건이 있습니다. 배치 관리자 권한이 없으면 로그온한 클라이언트의 잡만 보입니다. 권한 객체 S_BTCH_ADM의 BTCADMIN 값 Y는 모든 클라이언트에서 다른 사용자의 잡까지 다루는 관리자 권한입니다. SDM 잡은 기술 사용자의 잡이라, Y 없이 그 잡 로그를 열려면 S_BTCH_JOB의 PROT가 따로 필요합니다. Canceled 잡이 있으면 고른 뒤 Goto > Job Log로 원인을 봅니다. Canceled는 비정상 종료라는 뜻으로, 예를 들어 잡 단계의 ABAP 프로그램이 E나 A 메시지를 내면 이렇게 됩니다.

SDM_MON에서 상태를 읽는다

SDM 하나는 기술적으로 ABAP 클래스 하나입니다. SDM_MON(Silent Data Migration Monitor)은 기본으로 이 시스템에서 SDM을 일으키는 모든 클래스의 상태를 보여 줍니다. 상태는 여섯 가지입니다. 이름에 '적어도 한 클라이언트(at least one client)'가 붙은 상태는 한 클라이언트만 그래도 그렇게 표시되고, 모든 클라이언트에서 성공했다는 뜻은 Finished in all clients뿐입니다.

끝난 것으로 볼 수 있는 상태는 Finished in all clients와, 그 클라이언트에는 해당하지 않는다는 Not qualified for current target release 두 가지입니다. Waiting은 전제 조건을 기다리는 중이고 In process는 도는 중입니다. 도는 클래스는 줄을 고른 뒤 Migration Class in all clients > Migration Info로 끝날 날짜와 시각을 어림할 수 있습니다. Error는 자동으로 다시 실행되는 중이고, 열 번 실패하면 Cancelled가 됩니다. Cancelled인 클라이언트에서는 더 실행되지 않습니다. 이 글에서 확인한 SDMI 도움말과 전환 가이드에는 다시 돌리는 방법이 없고, FAQ인 SAP Note 2907976과 설정 옵션을 다루는 2916801은 읽지 않았습니다.

SAP 노트

SDM_MON 상태 여섯 가지

'적어도 한 클라이언트'는 한 클라이언트만 걸려도 표시된다

  • Finished in all clients

    • 모든 클라이언트에서 성공
    • 끝난 것으로 본다
  • Not qualified for current target release

    • 그 클라이언트에는 해당하지 않음
    • 끝난 것과 함께 센다
  • Waiting in at least one client

    • 전제 조건을 기다리는 클라이언트가 있음
    • 아직 진행 중
  • In process in at least one client

    • 아직 도는 클라이언트가 있음
    • Migration Info로 끝날 시각을 어림
  • Error in at least one client

    • 오류가 났지만 자동으로 다시 실행
    • 열 번 실패하면 Cancelled
  • Cancelled in at least one client

    • 그 클라이언트에서는 더 실행되지 않음
    • 기다려도 끝나지 않는다

상태 이름은 도움말의 영어 그대로입니다. 실제 화면 글자와 다를 수 있습니다.

끝난 것으로 볼 수 있는 상태는 Finished in all clients와 Not qualified 두 가지뿐입니다. Error는 스스로 다시 돌고, Cancelled는 더 돌지 않습니다.

목록이 길면 Show Only Qualified Migrations 보기로 바꿉니다. 이 시스템과 지금 릴리스에 해당하는 이전만 보여 주고, 되돌리지 않으면 다음에도 이 보기로 열립니다. 이 보기에서 Not qualified 줄이 빠지는지는 확인하지 못했습니다.

릴리스를 건너뛰면 달라지는 것

SDMI 하나는 적어도 한 릴리스 동안 업타임 실행을 지원합니다. 릴리스를 하나씩 거치면 이전을 모두 업타임에 돌릴 수 있지만, 건너뛰면 달라집니다. S/4HANA 1809에서 2020으로 바로 가면, 건너뛴 1909의 SDMI는 목표 릴리스에서 업타임 실행을 지원하지 않는 한 업무 다운타임에 돕니다. 시작 릴리스가 2020 이상이면 SDMI가 세 릴리스까지 업타임을 지원해, ZDO(Zero Downtime Option)로 최대 두 릴리스를 건너뛰어 세 번째 릴리스로 갈 수 있습니다. 2020에서 2023으로 가는 경우가 그 예입니다.

반대로 SDMI를 다운타임 안에서 끝내는 선택도 있습니다. SUM 2.0 SP27 가이드에 따르면 목표 릴리스가 S/4HANA 2021 이상인 업그레이드(2021 이상의 SP 업데이트 포함)에서 Configuration 단계의 Decision About Silent Data Migrations 대화창(단계 SUMASK_SDMI_DECISION)으로 고르며, ZDO에는 해당하지 않습니다. 앞의 1809→2020(목표 2020)이나 ZDO로 가는 2020→2023에는 쓸 수 없습니다. 고르면 SDMI는 사후 처리 단계 RUN_SDMI_POST_PROCESSING에서 돌고, 업무를 다시 시작할 때는 끝나 있습니다. 대신 SUM이 SDMI 잡을 동기로 돌리며 기다리므로 다운타임이 크게 늘고, 자원·이전 테이블 크기·다이얼로그 워크 프로세스·병렬화 설정에 따라 감당할 수 없을 만큼 길어질 수 있습니다. 배치 서버 그룹 SAP_DEFAULT_BTC에 이전을 돌릴 인스턴스가 있어야 하고, 권장 방식은 여전히 업타임 실행입니다.

SAP 노트

SDMI는 언제 도나

S/4HANA 업그레이드 경로와 SUM 선택에 따라

  • 릴리스를 하나씩 거칠 때

    • SDMI마다 적어도 한 릴리스는 업타임 지원
    • 이전을 모두 업타임에 돌릴 수 있다
  • 1809 → 2020 (1909를 건너뜀)

    • 건너뛴 1909의 SDMI는
    • 목표 릴리스에서 업타임을 지원하지 않으면 업무 다운타임에 돈다
  • 2020 → 2023 (ZDO)

    • 시작 릴리스 2020부터
    • 세 릴리스까지 업타임 지원
    • ZDO로 최대 두 릴리스를 건너뛰어 세 번째로
  • 다운타임에 강제 실행

    SUMASK_SDMI_DECISION

    • 목표 릴리스 2021부터 고를 수 있음
    • ZDO에는 해당 없음
    • RUN_SDMI_POST_PROCESSING에서 동기로 실행
    • 다운타임이 크게 늘어난다

S/4HANA 2025 전환 가이드(문서판 3.0)와 SUM 2.0 SP27 가이드 기준. 위 두 예(목표 2020, ZDO)에는 강제 실행을 쓸 수 없습니다.

릴리스를 건너뛰면 건너뛴 릴리스의 SDMI가 다운타임에 돌 수 있습니다. 다운타임 강제 실행은 목표 릴리스 S/4HANA 2021부터 고를 수 있고 ZDO에는 해당하지 않습니다.

끝났다고 적기 전에 볼 세 가지

이 점검을 미룰 수 없는 이유는 다음 업그레이드입니다. SDMI가 모든 클라이언트에서 끝나야 다음 릴리스 업그레이드를 시작할 수 있습니다. ZDO로 업그레이드할 때 SUM은 끝나지 않은 SDM 클래스를 찾으면 PREP_GENCHECKS/RUN_SDM_CHECK_STARTRELEASE 단계에서 오류로 멈추고, 모든 클래스가 끝나야 이어서 진행합니다.

그래서 순서를 정해 둡니다. 첫째, 클라이언트마다 SDM_USER에서 기술 사용자를 F4로 고르거나 만들고, SUM에서 무엇을 골랐든 업데이트 로그에 기술 사용자에 관한 P 메시지가 있는지 봅니다. 둘째, SM37에서 SAP_SDM_EXECUTOR_ONLINE_MIGR와 사용자 *로 잡을 찾고, Canceled가 있으면 잡 로그를 엽니다. 셋째, SDM_MON에서 모든 줄이 Finished in all clients 또는 Not qualified for current target release인지 봅니다. Cancelled 줄이 남아 있으면 끝났다고 적지 말고, FAQ 노트 2907976이나 SAP 지원으로 원인을 확인합니다. 업그레이드 완료 기록에는 SUM이 끝난 날이 아니라 셋째 확인이 맞은 날을 적으세요.

끝 · END OF NOTE
RSS 구독목록으로
COMMENTS BOX

이 기록에 대화를 더해 주세요.

궁금한 점, 다른 접근, 직접 해 본 결과를 나눠 주세요.

최신순

로그인 상태 확인 중…

댓글을 불러오는 중…