Hello SUM fans, this blog is a bit long and full of text, but it’s worth reading, as we have great news! 1. Homogeneous option for DMO SUM 2.0 SP 17 (available as of May 26th 2023) offers a homogeneous option for DMO! Until now, DMO was always heterogenous: the database type was always changed, for....
The use of automation has become very relevant for SAP ecosystems in the last few years. Many companies use it to deploy new workloads or migrate their existing ones to new platforms, like the cloud, namely to hyperscalers as it is a big trend. However the value of automation is much bigger than just for....
写在前面：本篇博客为翻译作品，希望帮助使用中文的客户通过更好地理解 SAP S/4HANA Cloud 更新/升级中所能使用的特性、功能和限制，帮助您更好地计划业务，整体提高使用产品的效率。 同时也感谢 Vincent Zhu （Vincent Zhu）在本篇翻译过程中所提供的建议！ 原作者是： Akshay Sharma (Akshay Sharma) 原文发布在：https://blogs.sap.com/?p=1648480?source=email-global-notification-mod 如今，客户希望云解决方案能够提供持续可用性，无需等待计划维护事件。他们期待软件部署不再中断其业务。这正是蓝绿部署（Blue-Green Deployment）方法帮助 SAP S/4HANA Cloud 实现的成果。 随着当前蓝绿部署能够支持基于 ABAP 的云系统的更新（hotfix 热修复）和升级（新版本发布），SAP S/4HANA Cloud 的停机时间为 5 分钟或更短。这一数字将计划进一步减少，直至到0。 本博客旨在向您介绍 SAP S/4HANA Cloud 更新/升级中使用的蓝绿部署方法，并讨论即使正在运行更新/升级，用户也可以使用的所有特性和功能。下面，我们开始吧！ 什么是蓝绿部署？ 蓝色和绿色仅指不同版本的两个运行时（runtimes）。如下图所示，蓝色是当前正在使用的生产运行版本，绿色是更新/升级之后的版本，最终将替换蓝色版本。 蓝绿部署 蓝绿部署的工作方式如下：使用者使用蓝色版本时；绿色版本将被并行部署。然后，当使用者切换为使用绿色版本时，蓝色版本将被移除。在上图中，“准备 V2”（“Preparing V2”）和“切换到 V2”（“Switching to V2”）阶段代表更新/升级阶段。 就是这样简单！ 这意味着更新/升级所需要做的更改都会在尽可能不影响用户的情况下被部署。在后台执行大部分更新/升级相关任务后，系统即切换到更新的版本，而更新后的系统即刻变为可用。因此，用户遇到的不允许登录系统的停机时间通过蓝绿部署将大大减少。 目前，SAP S/4HANA Cloud 中的所有....
本ブログはSAP標準のアップグレードツールである、Software Update Manager (通称SUM)を使ったアップグレードおよびコンバージョンプロジェクトのダウンタイム削減について紹介するページとなります。 ブログは以下3回を予定しており、本ブログはその２回目となります。 1．SUMダウンタイム削減概要 2．SUMダウンタイム削減（計画編） ← ここ 3．SUMダウンタイム削減（分析編） 記事の目的 前回のブログではコンバージョンやアップグレードにおけるSUMのダウンタイム削減概要について紹介しました。本ブログではプロジェクト計画時に、ダウンタイム削減の観点で考慮が必要な事項の紹介を目的としています。 対象読者 本記事の対象読者は前回のブログと同様、SAPのアップグレードやコンバージョンプロジェクトに関わることとなったSAP Basis担当者またプロジェクト管理者を想定しています。 SUMの実行時間削減の大前提 前回のブログでご紹介した通り、SUMが提供するダウンタイム削減手法はいずれもTechnical Downtimeの削減を目指した手法となります。 図：SUMフェーズにおけるUptimeとDowntimeの分類について そのため、Shadow Systemによって本番業務処理とSUMのコンバージョン・アップグレード処理が並行で実施されるUptimeフェーズを、業務ユーザがシステムアクセスができない状態としてしまうと、SUMの処理全体がシステムダウンとなり、SUMが提供するダウンタイム削減手法の効果が得られなくなります。このような状況となる具体的なケースは SAP S/4HANA コンバージョンの前提であるシステムのユニコード化が未実施のため、SUMの実行前にシステムコピーによるユニコードコンバージョンが必要 OS、DBのバージョンアップをSUMの実行と同じタイミングで行うため、SUMの実行前にOS、DBのバージョンアップが必要 コンバージョンやアップグレードの実施に合わせて、システムをクラウドにマイグレーションをするため、SUM実行前にシステムコピーが必要 などが考えれます。 いずれも、SUMの実行の前にシステムダウンが必要な処理があるため、SUMの開始時点から業務ユーザへのシステム解放を制限する方式となっています。 このような状態を回避するには、ユニコードコンバージョンやOS、DBのアップグレード、システムコピーなどの作業をSUMの実行とは別日に計画し、事前に完了させておく等の検討が必要となります。こうなると、SUMによるコンバージョン・アップグレードの他にもシステム停止日を設ける必要があるため、複数回の短いシステム停止日が取得しやすいのか、長いシステム停止が可能だが1度のシステム停止にする必要があるか、などを事前にシステムオーナーとご検討いただく必要があります。 SUMの実行時間短縮に最も効果のある方法 SUMの実行時間の短縮に最も効果のある方法は、強力なハードウェアを使用してSUM実行時のプロセス数を高く設定することになります。 SUMの処理では、ABAPプロセス、SQLプロセス、R3Transプロセス、R3Loadプロセス で処理がなされますが、それぞれの並列度はSUMのConfigurationフェーズで指定することが可能です。 図：Configurationフェーズで設定するプロセス数について それぞれのプロセスがSUM処理におけるどのような処理を担当するのか、また並列度の設定は何を元に決定すれば良いのかについては、以下のSAP Noteに記載されています。 SAP Note 1616401 – Parallelism in the Upgrades, EhPs and Support Packages implementations たとえば、R3TransプロセスはSUMの処理の中でも、サポートパッケージのインポート処理に使用され、DDIC_UPG、SHADOW_IMPORT、TABIM_UPGといった処理で使用されるプロセスになります。 R3transプロセスの並列度の推奨値はCPUの数と同じ数となるため、なるべくCPUの数が多い強力なハードウェアを用いて並列度を高く設定することが推奨されます。これにより、R3Transプロセスを使うSUM処理の実行時間削減が可能です。その他のプロセスについても、同SAP....
本ブログはSAP標準のアップグレードツールである、Software Update Manager (通称SUM)を使ったアップグレードおよびコンバージョンプロジェクトのダウンタイム削減について紹介するページとなります。 ブログは以下3回を予定しており、本ブログはその3回目となります。 1．SUMダウンタイム削減概要 2．SUMダウンタイム削減（計画編） 3．SUMダウンタイム削減（分析編） ← ここ 記事の目的 前回のブログではコンバージョンやアップグレードのプロジェクト計画時に、ダウンタイム削減の観点で考慮が必要な点を紹介しました。本ブログではSUMの実行が完了した後、SUMが出力するアップグレード分析ファイルをもとに、ダウンタイム削減の余地を分析する手法について紹介します。 対象読者 本記事の対象読者は前回のブログと同様、SAPのアップグレードやコンバージョンプロジェクトに関わることとなったSAP Basis担当者またプロジェクト管理者を想定しています。 SUMのアップグレード分析ファイル（UPGANA.xml） SUMによるコンバージョンやアップグレード処理が正常終了すると、SUM実行の分析レポートが利用可能となります。レポートはUPGANA.xmlという名称のファイルで、<SUM directory>/abap/doc/analysis 配下に格納されます。このレポートでは次に示すような情報を確認でき、次回のSUM実行に向けたチューニングポイントを確認するための情報を提供しています。 ソフトウェアバージョンやデータベースサイズ情報 選択したダウンタイム削減手法やプロセス数 SUMの処理実行時間 各ステップで要した時間 大きなデータベーステーブル UPGANA.xmlを使ったSUMの実行時間削減の分析 SUMの実行時間を削減するためには、SUM処理の中でも時間を要しているフェーズや処理にフォーカスして、処理時間短縮を行う必要があります。UPGANA.xmlではRoadmap Stepsというセクタを展開して表示すると、SUMにおける詳細な処理ステップ単位での実行時間を確認することが可能です。 例えば、下の図のようにExecutionフェーズでは合計で18時間45分の処理時間を要しており、その中でもXPRAS_AIMMRGという処理に11時間22分の処理時間を要しているということが確認できます。 このようにSUM処理の中でも長時間の実行時間を要している処理を見つけ、その改善方法を探索し、解決策を実装することでSUM処理の実行時間を削減が可能となります。 SUM処理の中でも長時間実行される処理は多くのお客様で共通しているため、改善方法はSAP Noteで提供されているケースが多いです。そのため、まずは改善したい処理名称でSAP Note検索を行ってください。 ここからは、良く参照される処理名とSAP Noteをいくつか紹介いたします。 EU_CLONE_MIG_DT_RUN この処理はNon HANAのソースDBからターゲットのHANA DBにデータをマイグレーションする処理で、R3loadプロセスが使われる処理となります。SUMのDatabase Migration Option（通称DMO）を使用した時に実行される処理になります。 本処理のパフォーマンスの分析方法はSAP Note 2597701 – Performance analysis for EU_CLONE_MIG_DT_RUN....
Today, customers expect that cloud solutions should offer continuous availability, sparing them the need to wait for planned maintenance events. They prefer that software deployments do not disrupt their businesses anymore. And this is exactly what Blue-Green deployment methodology helps SAP S/4HANA Cloud achieve. With the current Blue-Green deployment supported updates (hotfix) and upgrades (release)....
本ブログはSAP標準のアップグレードツールである、Software Update Manager (通称SUM)を使ったアップグレードおよびコンバージョンプロジェクトのダウンタイム削減について紹介するページとなります。 ブログは以下3回を予定しており、本ブログはその1回目となります。 1．SUMダウンタイム削減概要 ← ここ 2．SUMダウンタイム削減（計画編） 3．SUMダウンタイム削減（分析編） 記事の目的 SUMのアップグレードおよびコンバージョン処理におけるダウンタイム削減についてはBoris Rubarthさんを筆頭に多くの記事があります。今回、それらを参考にしながらダウンタイム削減の手法や分析の仕方について整理し、紹介することを目的としています。 各ダウンタイム削減手法はTechnical Downtimeの削減に焦点を当てたものとなっております。そのためTechnical Downtimeとは何かを理解することがSUMによるダウンタイム削減を考える上での最重要なポイントとなるため、この点についても紹介をしております。 対象読者 本記事の対象読者はSAPのアップグレードやコンバージョンプロジェクトに関わることとなったSAP Basis担当者またプロジェクト管理者を想定し、SUMを使用したアップグレード/コンバージョンのダウンタイム削減にどのような対応がとれるかを理解していただくことを目標としています。 Software Update Managerについて Software Update Manager (通称SUM) はSAPシステムのUpdateやUpgrade、S/4 Conversionを行うためのSAP標準ツールです。SUMのバージョンは現在1と2があり、バージョン1はSAP NetweaverのJavaスタック、デュアルスタック、ターゲットバージョンが750以下のABAPスタックに使用され、バージョン2はターゲットバージョンが750以上のABAPスタックに使用されます。 参考情報：https://support.sap.com/en/tools/software-logistics-tools.html Software Update Managerが扱うSAPシステムメンテナンスの範囲は多岐にわたり、SAP ECC 6.0のサポートパッケージスタック (SPS) の適用、エンハンストメントパッケージ (EHP) の適用、SAP ECC 6.0からSAP S/4HANAへのシステムコンバージョン、SAP S/4 HANAのバージョンアップグレード、SAP S/4 HANAのSPS適用、Non-HANADBからSAP HANA DBへの移行を伴ったアップグレードやシステムコンバージョンなど様々な用途で使用します。 また、標準で利用できるダウンタイム削減のオプションも複数存在しており、near-Zero Downtime Maintenance (通称nZDM)、Zero Downtime Option....
You are working on a migration scenario to SAP HANA database using Software Update Manager (SUM) with its Database Migration Option (DMO). You wonder which SAP HANA log mode the tool is using during the migration. The available log modes of SAP HANA database are explained in the documentation, for example using the following link https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/c486a0a3bb571014ab46c0633224f02f.html. Relevant statements....
Sure, you know that we have Software Update Manager (SUM) 2.0 already out for quite a while – in previous times, SUM 1.0 was the only kid on the block. Note: after my initial explanation (“SUM in the family way”) as a blog post in this SAP Community, we have moved the explanation of SUM....
As promised, part2 is in continuation to my blog post https://blogs.sap.com/2022/03/25/soh-migration-sum-dmo-with-system-move-first-hand-experience-part-1 In this blog post we will cover the following. How to effectively use DURATIONS file (MIGRATE_DT_DUR.XML) to reduce downtime. An out of the box solution to fast forward the downtime stage. SUM parallel mode execution Let’s start with how MIGRATE_DT_DUR.XML file can contribute. Durations.xml When....
Last Changed: 05th of April 2022 while the Installation and (Basis) Configuration of SolMan 7.2 is really a complex task, it shows that the correct Implementation of the Diagnostic Agent become an even more complex task. Blog – SAP MacGyver – Installing SAP SolMan 7.2 Install and connect the SAP Diagnostic Agent properly It is always....