In the last 10 years I have patched a lot of SAP systems and the last 5 years mostly HANA systems. Technically the update of the HANA DB is no rocket science. The patching process itself will take round about 10-20min. So most of you may say what is so special that I have to read a blog about it? Here I can make the answer short => because HANA has a lot of dependencies and depending on how you use it you have to configure it in a special way.
Dependencies:
So, what I want to explain is not the technical update part. It is more like which checks do I have to perform to harmonize all components of my system. This is the part which will take most of your time and you will freak out how many SAP notes you have to check 😉 But in the end you have a stable system, and this is worth to read and adjust your process.
So, if your systems currently running fine and a certified expert has set them up, all components are configured on the basis of SAP notes, guides and best practices from the install date. For example, now you want to upgrade to the latest HANA 2.0 SPS03 revision 34. What do we have to check before we can patch?
Is your application supported for the target revision? Check it via PAM (product availability matrix)
1) Does the sizing still meet your application requirements?
There are multiple ways to check this:
- HANA Sizing report => yes, you still can execute it also your already on HANA
- Scripts of notes 1969700
2) Does the sizing still meet the server/storage hardware requirements and prerequisites of your target HANA revision?
If you answer this with
- no, increase resources if your systems are virtualized, buy new hardware or migrate it to hardware which meet the prerequisites
- yes, go forward to the next check
3) Is your system virtualized?
Check if your hypervisor is certified for HANA 2.0 SPS03 and the combination of your server hardware and OS.
For instance Haswell CPUs (v3) are not certified for VMware 6.5/6.7
Another example is SLES11 (BE) on Power is not certified for HANA 2.0. Here you have to install a new LPAR with >SLES12 (LE) or RHEL 7.3 to meet the requirements.
=> HW is ready for HANA 2.0? Ok here we go for the next checks. By the way recommendation is min. Intel Haswell or Power8
1) OS Check
For HANA 2.0 SPS03 Rev. 34 I recommend:
You find the lifecycles for SUSE and RHEL on their websites.
2) OS SW components and Kernel settings
In the meanwhile the SAP notes may have changed and have new requirements and new parameters
a) update to the latest kernel
b) update to the latest SW components
c) check the notes / best practice guides for new parameters => OS notes, HW vendor guides and the optimized network configuration for HANA (2382421)
3) Verification with HWCCT landscape check
Therefore you should use hwcct 2.0 for your specific revision. Adjust your settings if there are any warnings or errors.
=> Ok now you have your 'golden image' for your systems which has to be frozen to avoid any unwanted change
1) Check your update path
If your system is too old you may have to go for an additional step. For instance you are on HANA 1.0 SPS12 122.03. In this case you have to upgrade to the latest revision in SPS12 and then upgrade to Rev. 34. There are some dependencies you have to keep an eye on.
Another case if you are on a pretty new release of SPS12 => 122.21. The only way to upgrade is to 35 and higher. So, if you reread the first example you may notice that if you have to go for an additional step you may end up in a revision which is not allowed to upgrade to your target revision 34. Sound wired but it is also a scenario which can happen.
1948334 - SAP HANA Database Update Paths for SAP HANA Maintenance Revisions
2) Check your target revision for known issues
This is the part which most of my customers have never done, because it takes so much time. There is currently no automatism which can check your source and target revision for known issues. Currently in SPS03 there are up to 200 issues which have to be manually checked. This can take up to 5 days depending on your revision. So, I have created a database (currently about 2000 notes as content) for my customers to support them to create an optimal and stable core for there individual business scenario. I already talked to a lot of people at SAP and also created a request at idea place / customer influence 2 years ago (Apr 20, 2016), but till now nothing happened.
For every support package stack (SPS) there are collection notes.
In our case:
2688515 - SAP HANA DB: SAP HotNews in HANA 2.0 SPS03
2628684 - SAP HANA DB: Known issues detected in Hana 2.0 SPS03
2600030 - Parameter Recommendations in SAP HANA Environments
This should be combined with the parameter script of Martin Frauendorfer from note 1969700.
3) Update SAP Kernel
Ok everyone knows that the SAP Kernel consists of 2 parts:
- SAPEXE which is independent from the database (disp+work, R3trans, tp etc.)
- SAPEXEDB which depends on the database (libdbsl, R3load, R3ta etc.)
But there is also a third component which is also essentially for running a SAP system on HANA. Do you know it? It is the SQLDBC. Another acronym of SAP for SQL database client.
You can have a newer SQLDB version with an older HANA revision, but you should not it the other way around. It can work, but if you use newer hints and features of the DB it can have bad side effects. So note every time you plan to change the SAP kernel, change also the HANA database client on the application server.
4) Consistency Check
Normally this part should be frequently scheduled as part of your operations manual. You have to run one before the upgrade and one after. Why? Because there might be some checks which were added in the target revision and can report errors which couldn't be found in the source revision.
5) Backup HANA DB + configuration
Ok a backup before the upgrade is normal, but why I additionally list the DB configuration? The config is not part of the backup set. So, you have to backup it manually via file backup.
6) Is there any need of defragmentation / reorganization on tables in memory or on disk?
Check the mini checks and the additional check in the section of memory and disk with the scripts from note 1969700.
7) Update Host Agent
Download the latest Host Agent. Now you think why I should download it although it is part of the install files of the target revision. When the revision bundle was laced up this was 4-6 weeks before the official release and this means an old Host Agent is part of it. Please keep in mind that since version 39 (2382421) you have to configure the agent manually when using the HSR (HANA system replication).
Thanks to all SAP mentors who I met this SAP TechEd in Barcelona to motivate me to write another blog in context of SAP HANA. Special thanks to craig.cmehil and svea.becker for the support.
######
edit
######
V1.1 Insert OS picture and linked support lifecycle
Dependencies:
- Server (HANA Certification)
- Hypervisor (HANA Certification)
- OS (Kernel + Settings)
- SAP Kernel
- SQLDBC = SQL Database Client = HDB Client
So, what I want to explain is not the technical update part. It is more like which checks do I have to perform to harmonize all components of my system. This is the part which will take most of your time and you will freak out how many SAP notes you have to check 😉 But in the end you have a stable system, and this is worth to read and adjust your process.
So, if your systems currently running fine and a certified expert has set them up, all components are configured on the basis of SAP notes, guides and best practices from the install date. For example, now you want to upgrade to the latest HANA 2.0 SPS03 revision 34. What do we have to check before we can patch?
Application check
Is your application supported for the target revision? Check it via PAM (product availability matrix)
HW Checks
1) Does the sizing still meet your application requirements?
There are multiple ways to check this:
- HANA Sizing report => yes, you still can execute it also your already on HANA
- Scripts of notes 1969700
2) Does the sizing still meet the server/storage hardware requirements and prerequisites of your target HANA revision?
If you answer this with
- no, increase resources if your systems are virtualized, buy new hardware or migrate it to hardware which meet the prerequisites
- yes, go forward to the next check
3) Is your system virtualized?
Check if your hypervisor is certified for HANA 2.0 SPS03 and the combination of your server hardware and OS.
For instance Haswell CPUs (v3) are not certified for VMware 6.5/6.7
Another example is SLES11 (BE) on Power is not certified for HANA 2.0. Here you have to install a new LPAR with >SLES12 (LE) or RHEL 7.3 to meet the requirements.
=> HW is ready for HANA 2.0? Ok here we go for the next checks. By the way recommendation is min. Intel Haswell or Power8
SW Checks
1) OS Check
For HANA 2.0 SPS03 Rev. 34 I recommend:
- SLES12 SP3 (because SLES12 SP2 will reach general support end in 04/2019) => SAP note 2205917
- SLES15 => SAP note 2684254
- RHEL 7.3 => SAP note 2292690
You find the lifecycles for SUSE and RHEL on their websites.
2) OS SW components and Kernel settings
In the meanwhile the SAP notes may have changed and have new requirements and new parameters
a) update to the latest kernel
b) update to the latest SW components
c) check the notes / best practice guides for new parameters => OS notes, HW vendor guides and the optimized network configuration for HANA (2382421)
3) Verification with HWCCT landscape check
Therefore you should use hwcct 2.0 for your specific revision. Adjust your settings if there are any warnings or errors.
=> Ok now you have your 'golden image' for your systems which has to be frozen to avoid any unwanted change
HANA Checks
1) Check your update path
If your system is too old you may have to go for an additional step. For instance you are on HANA 1.0 SPS12 122.03. In this case you have to upgrade to the latest revision in SPS12 and then upgrade to Rev. 34. There are some dependencies you have to keep an eye on.
Another case if you are on a pretty new release of SPS12 => 122.21. The only way to upgrade is to 35 and higher. So, if you reread the first example you may notice that if you have to go for an additional step you may end up in a revision which is not allowed to upgrade to your target revision 34. Sound wired but it is also a scenario which can happen.
1948334 - SAP HANA Database Update Paths for SAP HANA Maintenance Revisions
2) Check your target revision for known issues
This is the part which most of my customers have never done, because it takes so much time. There is currently no automatism which can check your source and target revision for known issues. Currently in SPS03 there are up to 200 issues which have to be manually checked. This can take up to 5 days depending on your revision. So, I have created a database (currently about 2000 notes as content) for my customers to support them to create an optimal and stable core for there individual business scenario. I already talked to a lot of people at SAP and also created a request at idea place / customer influence 2 years ago (Apr 20, 2016), but till now nothing happened.
For every support package stack (SPS) there are collection notes.
In our case:
2688515 - SAP HANA DB: SAP HotNews in HANA 2.0 SPS03
2628684 - SAP HANA DB: Known issues detected in Hana 2.0 SPS03
2600030 - Parameter Recommendations in SAP HANA Environments
This should be combined with the parameter script of Martin Frauendorfer from note 1969700.
3) Update SAP Kernel
Ok everyone knows that the SAP Kernel consists of 2 parts:
- SAPEXE which is independent from the database (disp+work, R3trans, tp etc.)
- SAPEXEDB which depends on the database (libdbsl, R3load, R3ta etc.)
But there is also a third component which is also essentially for running a SAP system on HANA. Do you know it? It is the SQLDBC. Another acronym of SAP for SQL database client.
You can have a newer SQLDB version with an older HANA revision, but you should not it the other way around. It can work, but if you use newer hints and features of the DB it can have bad side effects. So note every time you plan to change the SAP kernel, change also the HANA database client on the application server.
4) Consistency Check
Normally this part should be frequently scheduled as part of your operations manual. You have to run one before the upgrade and one after. Why? Because there might be some checks which were added in the target revision and can report errors which couldn't be found in the source revision.
5) Backup HANA DB + configuration
Ok a backup before the upgrade is normal, but why I additionally list the DB configuration? The config is not part of the backup set. So, you have to backup it manually via file backup.
6) Is there any need of defragmentation / reorganization on tables in memory or on disk?
Check the mini checks and the additional check in the section of memory and disk with the scripts from note 1969700.
7) Update Host Agent
Download the latest Host Agent. Now you think why I should download it although it is part of the install files of the target revision. When the revision bundle was laced up this was 4-6 weeks before the official release and this means an old Host Agent is part of it. Please keep in mind that since version 39 (2382421) you have to configure the agent manually when using the HSR (HANA system replication).
Thanks to all SAP mentors who I met this SAP TechEd in Barcelona to motivate me to write another blog in context of SAP HANA. Special thanks to craig.cmehil and svea.becker for the support.
######
edit
######
V1.1 Insert OS picture and linked support lifecycle
- SAP Managed Tags:
2 Comments
