먼저 간략하게 말씀드리면 SAP에서 제공하는 SUM 툴을 통해 Conversion 작업이 진행됩니다. SUM 버전에 따라 기존 DB버전의 업그레이드가 필요 할 수 있으며, Conversion 작업 전에 Unicode conversion이 완료되어야 하는데 이부분을 최종 Conversion 작업시 진행할 것인지 사전에 수행할 것인지는 종합적으로 고려해 보아야 합니다. 자세한 문의사항은 http://www.his21.co.kr/his/support/productinquiry/index.do 로 문의주시기 바랍니다.
HANA DB에 대해서는 DB Memory Sizing 작업을 통해 HW를 선정하고, ERP AP서버에 대해서는 기존 HW의 SAPS를 환산하여 S/4HANA 버전에서의 예상되는 부하를 고려한 가중치 부여를 통해 산정하게 됩니다. 최근 S/4HANA 1809버전부터는 AP서버로 선정 가능한 OS버전이 대폭 축소되었습니다. Notes 2620910 - SAP S/4HANA 1511, 1610, 1709 and SAP BW/4HANA 1.0: Recommended Application Server Platforms 자세한 문의사항은 http://www.his21.co.kr/his/support/productinquiry/index.do 로 문의주시기 바랍니다.
고객사의 규모, 사정에 따라 선택하는 방식이 상이합니다. Public Cloud로 전환을 고려하는 고객은 아직까지는 중소기업 또는 대기업의 인프라가 열악한 해외 지사 일부에서 고려되고 있습니다. 참고로 Public Cloud로 전환시에는 Legacy 시스템과의 I/F를 위한 전용선 구축, SLA에서 보장하는 시스템 가용성 시간등을 종합적으로 고려해서 결정하셔야 합니다.
변경되거나 삭제된 DB Object와 관련된 개발 Object는 모두 ATC(Abap Test Cockpit)으로 도출이 가능하며, 관련 구조에 맞게 프로그램을 변경하시면 대부분 재사용이 가능합니다. CBO 프로그램 전환비용은 진단 서비스를 통해 제공가능합니다. 자세한 사항은 http://www.his21.co.kr/his/support/productinquiry/index.do 로 문의주시기 바랍니다.
사용자가 체감하는 응답속도는 크게 Network time과 Transaction time으로 나눌 수 있습니다. SU01(사용자 생성) 처럼 기능이 복잡하지 않은 화면은 HANA로 전환이 되어도 실제 체감적인 성능 차이는 그렇게 크지 않습니다. 왜냐하면 이런 화면은 기존 Oracle DB에서도 워낙 짧은 시간을 소요하기 때문입니다. 그러나 백그라운드 작업으로 MRP 작업이 10시간 이상 수행되었던 고객이라면 성능상의 개선 효과는 눈에 띄게 확인하실 수 있을 거라 생각 됩니다. Conversion 프로젝트 시에 주어진 기간 및 개발 리소스를 고려시 모든 개발프로그램에 대해 튜닝을 할 수 없기 때문에 가장 응답시간이 오래 걸리고, 사용량이 많은 프로그램 위주로 우선 순위를 정해서 튜닝을 진행하시면 될 것 같습니다. 문제가 되는 개발 코드는 ATC(Abap Test Cockpit)으로 식별이 가능합니다.
SAP ECC에서 관리하는 비정형데이터라면 주로 첨부파일(예 : FI-전표 증빙, PM-전자 도면 등)과 같은 형태일 것으로 추정되는데요. 이런 유형의 파일을 SAP ECC 테이블에 저장되어 있다면 HANA DB로 Conversion 하는 것이 불가능 하지는 않습니다. 다만, HANA HW 가격을 고려시 추천 드리지 않습니다. 이런 파일은 Conversion 시 SAP Contents 서버 또는 Opentext(아카이빙 솔루션)으로 이관하실 것을 권고 드립니다.
1. Unicode 적용 여부, DB 압축 상태 등에 따라 향후 HANA Sizing결과가 달라집니다. Non-Unicode, 20TB Oracle DB를 사용중인 고객 사례의 경우 Conversion 후 초기 Memory Sizing은 4.7TB 였습니다. 2. 현 Sky-lake CPU 기준으로 Hitachi가 보유한 Scale-Up 최대 지원 가능 용량은 12TB입니다. 내년에 Cascade lake CPU기반 HANA Appliance 출시 시점에는 최대 지원 가능 용량이 현재 보다 3배 이상 증가 됩니다. 3. Scale-Out 구성 (Notes 2408419 - SAP S/4HANA - Multi-Node Support_ 최대 4+1 node 구성, Node당 8소켓 6TB이상의 HW 필요-인텔 CPU기준 자세한 사항은 http://www.his21.co.kr/his/support/productinquiry/index.do 로 문의주시기 바랍니다.
답변을 원하실 경우, http://www.his21.co.kr/his/support/productinquiry/index.do 로 문의 부탁드립니다.
HANA DB를 Public 클라우드로 구축하는 사례는 최근 일부 중소기업에서 사례가 있습니다. 대표적인 이유로는 HW비용 절감 목적보다는 시스템 관리(SM) 인원 감축 및 관련 비용 절감(교육비, 퇴직충당)의 목적이 크며 그외에 해외 오지에서 제한된 인원의 사용 목적등으로 초기 투자비용이 과도하게 들어 가기 때문에 선택하는 경우라고 볼 수 있습니다. 그러나 클라우드 선택 시 추가로 legacy 시스템(POP, MES, 3rd Party HR 등)과 S/4HANA간 빈번한 I/F를 처리를 위한 별도의 전용선 비용, IaaS 업체에서 제시하는 SLA에 명시된 가용성 보장 항목, 서비스 중단 시 보상기준 등을 다각도로 고려하여 검토하셔야 합니다.
Conversion 진단과정 중에 ATC(Abap Test cockpit)을 통해서 기존 개발된 프로그램의 수정 사항 및 성능에 영향을 주는 개발 오브젝트에 대해 list-up 가능하며 이를 기반으로 Conversion 프로젝트 도중에 해당 개발오브젝트에 대해 수정 및 테스트를 진행하게 됩니다. 타 컨설팅 업체의 경우 Conversion 프로젝트 기간(대략 6개월) 동안 이런 일련의 점검을 반복적으로 수행해주는 SAP사의 Value Assurance Service라는 유료 서비스를 별도로 권장하기도 합니다.
기본적으로 Disk 기반 RDBMS 대비 HANA DB로 전환시 압축률이 높기 때문에 DB Size가 많이 줄어듭니다. 다만, DB level 또는 스토리지 level에서 이미 DB를 압축하여 운영중이라면 S/HANA로 전환하더라도 DB Size가 드라마틱하게 많이 줄어 들지는 않습니다. 그리고 기존 개발 프로그램에서 트랜젝션 처리를 위해 표준테이블의 데이터를 복사해서 중복 관리하는 로직 유무, 증가하는 데이터의 성격(예 : Distinct Value, 첨부 파일 등)에 따라서 DB size 산정이 달라 집니다. 자세한 사항은 별도로 문의주시기 바랍니다.
HANA DB에서 특정 테이블의 데이터를 메모리에 load할지 말지를 설정하는 옵션이 존재하지만 이는 초기 조회시 속도 향상을 위해 존재하는 옵션이기 때문에 HW resizing과 연관이 없고, HW Sizing과 관련이 있는 부분은 S/4HANA 에서 제공하는 Data Aging입니다. 관련 Notes 2416490 - FAQ: SAP HANA Data Aging in SAP S/4HANA 을 참고 하시기 바랍니다.
문의하신 질문은 SAP 아카이빙 업체에 문의 하셔야 하는 사항입니다. 다만, 아카이빙 오브젝트 및 ADK는 모두 SAP에서 제공하는 것으로 SAP 아카이빙 관련 데이터의 신뢰성은 보장된다고 봐야 합니다. 일반적으로 아카이빙되어 이미 기존 DB에서 삭제된 데이터를 다시 복구하는 것은 긴급상황 아니면 권장하지 않습니다. 왜냐하면 아카이빙 시점의 DB 구조와 Customizing 설정이 시간이 지나면서 변경되어 다시 아카이빙된 데이터를 복구 할때 문제가 발생할 가능성이 높기 때문입니다. https://help.sap.com/viewer/c6ef916aeac74db0a6bec2142bc00248/6.18.11/en-US/6d7a3bb7-6e6e-4fff-a98e-a132fabb1335.html?q=Reload%20of%20archived%20data
백업센터(DR)을 Conversion 프로젝트 중에 구성하게 되면 아무래도 DR구성 후 여러 복구 시나리오를 가정한 테스트 시 실제 운영시스템이 가동중에 있지 않기 때문에 자유로운 테스트가 가능합니다. 이 부분이 가장 큰 장점이 아닐까 합니다. 만약 운영중이라면 별도의 일정을 잡아야 하고, Legacy 시스템에서 지속적으로 발생되는 I/F 데이터의 차단 등을 종합적으로 고려하여야 하기 때문에 아무래도 테스트를 원활하게 수행하기 어려울 것입니다. (예 : 운영서버 장애 가정하에 DR센터로의 SAP 서비스 전환, 다시 DR센터의 서비스를 운영서버로의 역 Sync)
본 세미나 주제와 관련없는 문의사항입니다만.... 백업 S/W 및 버전, HANA DB버전, Backup N/W, Backup 관련 Parameter 설정 사항등을 종합적으로 고려해야 하므로 아래 문서를 참고해 주시기 바랍니다. https://launchpad.support.sap.com/#/notes/1730932 https://launchpad.support.sap.com/#/notes/1642148 https://launchpad.support.sap.com/#/notes/1835075 https://blogs.sap.com/2017/05/04/hana-backup-and-recovery-multi-streaming-data-backups-with-third-party-backup-tools/
본 세미나 주제와 관련없는 문의사항이지만 간략히 아는 상황에서 답변드립니다. 2025년 이후에는 SAP에서 ECC 6.0버전에 대한 Support Package등의 제공이 되지 않을 것으로 예상됩니다. 반드시 Support Pakcage 적용을 통해 최신 Patch 상태로 관리 해야 하는 고객의 경우(예 : SAP HR모듈 사용-연말정산 건강보험료율의 매년 변동사항을 SAP에서 HR Support Package로 제공)에는 3rd Party 유지보수 업체에서 이런 부분에 대해 확인이 필요해 보입니다.