on 09-11-2012 3:59 PM
So, we have a landscape, where a productive ECC system is connected to a productive SLT server and data is replicated to a productive HANA appliance.
Data is initially loaded, the tables are fully replicated and we can see that everything is working well.
The ECC accelerated scenario works perfectly and end users are impressed with the performance improvement.
I'd like to drop in 2 maintenance scenarios and ask for your feedback on how to ensure this landscape remains consistent and error free.
Scenario 1
There is a planned downtime for the ECC source system to enable a kernel upgrade and to perform some database performance maintenance not related to the accelerated application
Scenario 2
There is a planned downtime for the productive SLT server to update the active kernel to the newest version
As both are "planned downtime scenarios" I'd like to come up with a strategy to ensure all 3 aspects of the working landscape remain in a consistent state.
I do have some thoughts on this, but would appreciate some feedback from the Community on their experience of similar scenarios.
The kind of things I am thinking about are :
Do I only have to stop the master jobs in SLT ?
Do I need any manual intervention in the HANA Data Replication area to ensure consistency ?
Are changes to table structures in the source system automatically carried across to HANA on restart ?
Thanks
Simon Jackson.
Hi Simon,
Im not able to answer your question in full but on the HANA side I would like to point out the following.
In the modeler under 'data provisioning' you can see the tables which are being replicated in your current HANA environment from SLT. Here you have several options including Load, Replicate, Stop Replication, Suspend, and Resume. It is import to note the differences in these options as you will need to adjust the loading of your HANA environment during system down times etc.
The key differences here is to note the difference between Suspend and Stop Replication. SLT works on 2 assumptions.
If you stop replication and re-start it the corresponding table will be DROPPED. Initial load MUST be repeated as delta recording deactivated and changes not recorded.
If you suspend replication then resume you DO NOT need to re-do the initial load as the delta recording is not dropped.
I hope this makes sense on the HANA side.
Kind regards,
Danielle
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Danielle
Thanks for the heads up on the data replication view in the data provisioning section of STUDIO - not had much time to take a look at how these options work.
If I'm right, then I can suspend replication for all active replicated tables, enter into the maintenance scenarios I discussed, then resume the replication again ?
Is this correct ?
I also wondered - do I have to stop the master jobs in SLT for either of the scenarios I mention ?
You may be interested in a situation we had this week for our non-prod set up.
Replication was working fine for the regression landsacpe ( ECC to SLT to HANA ) but someone in the project team decided it was a good idea to stop the ECC system without informing us - not good for the status of the tables in HANA. When the regression system was restarted, HANA was fine.
My infrastructure managers are very interested in how we manage HANA in an active landscape right now, so your reply is appreciated.
Simon.
Hi Simon,
I understand your concern and think it best to review the following as they will be very benefitial in helping you to answer your questions. Unfortunately I have not have direct experience in this area as integration is managed for the most part by out BASIS team. I would however start with this:
All guides can be found at http://help.sap.com/hana_appliance , from here you can search for SLT related content.
Also check out SLT related notes. This one (1605140) holds alll relevant notes.
SAP Note Number | Short Text | Description |
19466 | Downloading SAP Kernel patches | Downloading a kernel patch in the Service Marketplace, Software Distribution Center. |
517484 | Inactive services in the Internet Communication Framework | The Internet Communication Framework Services are inactive when you install the SAP Web Application Server. |
1468391 | Installation and delta upgrade of DMIS 2010_1 | The SAP Landscape Transformation component part of DMIS. |
1597627 | HANA Connection | Activating a secondary connection to the SAP HANA In-Memory Database |
1603660 | Individual release 7.20 kernel on MaxDB for HANA LT | Using 7.20EXT kernel with MaxDB |
1646371 | HANA replication for 4.6C source systems | For 4.6C source systems |
1605140 | SAP HANA: Central Note - SAP LT Replication Server | Collective Note for all the relevant Notes for LT Replication Server for HANA |
1709225 | Installation / Upgrade LT Replication Server - DMIS 2010 SP7 | This SAP Note describes the installation or upgrade of the LT Replication Server to DMIS SP07 |
Read through the following and search on keywords like outage.
The above guides provide information such as the following:
4.1.3 Stopping jobs
In the Configuration & Monitoring Dashboard (tab page Job and Connections), you can suspend the load and / or replication for all tables of a configuration using the pushbutton Stop for the master job. The master job stops as well all related jobs of a configuration – initial load and / or replication will immediately discontinue – however, a database trigger in the source system(s) will continuously record changes in the log tables.
Note: As an alternative to automatically temporarily stopping and restarting the replication after a certain point in time, you can switch the replication mode in the tab page Settings from “Real time” to “Schedule by time”.
4.1.4 Restarting jobs
If you stopped the master job of a configuration, or if it was aborted, you can restart the master job from the Configuration & Monitoring Dashboard (tab page Jobs and Connections). The master job resumes as well as all related jobs.
How can I ensure that data is consistent in the source system and SAP HANA system?
Since any change in the source system is tracked in dedicated logging tables, the replication status for each changed data record is transparent. A entry of a logging table is deleted after a successful "commit" statement from the SAP HANA database, this procedure guarantees data consistency between source and target (SAP HANA) system – even in the case of system outages or network failures. Advanced monitoring and further expert functions allow you to track the replication progress of each data portion in detail – however, dedicated reconciliation lists that allow reviewing the replication status from a business perspective are currently not available.
What happens in case of network failures?
As long as there was no successful "commit" statement from the SAP HANA database, respective information in the logging tables stay in place – therefore the replication of related changes will be repeated until the replication is successfully completed.
Hope this helps.
Kind regards,
Danielle
Simon:
SLT is like any other source system that feeds or loads data via ECC connectivity. During system down-time or maintenance we will have to systematically bring down the system using respective options (suspend or resume) to avoid adverse effects.
Regards,
Rama
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
85 | |
10 | |
10 | |
9 | |
6 | |
6 | |
6 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.