I blogged last year about a programme of work to run several upgrades and Unicode conversions on multi-terabyte SAP Systems for a client. Finally I have been able to pull together a series of posts which will detail the work, the challenges and the solutions we implemented during the programme. The upgrade programme lasted for 10 months and covered a number of projects,
- The upgrade projects (Listed below)
- A Data Centre migration and support migration to an outsourcing supplier (Run by the client and the outsourcing supplier)
- Hardware migration (As part of the DC move)
These blogs will focus on the upgrade of the ECC system, for the simple reason that it was the one I was closest to, although I will talk about the other upgrades and the challenges they posed. At the start of these projects it is important to have strong idea on how to execute the upgrade and Unicode process, I use the word idea because at this point it is an idea; it has not been validated by anything other than experience from other projects. I looked at the overall programme of work being executed at the client and the client’s roadmap for the future and developed an end-point of where the systems should end up at the end of the project – this is detailed in the table below
Once I had decided on the versions of the O/S, the database and the SPS levels of the applications, the main consideration is how do you get to those versions. The SPS levels are quite easy as they can be integrated into the upgrades and handled during the upgrade runtime. The O/S and DB versions changes are usually handled outside the upgrade process, but they can be interwoven with Unicode conversions depending on the scenario and so it is important to look at what else is going on within the landscape to see what options are available to you to achieve your aims – for me my saving grace was to be the data centre migration.
The diagrams below show two options available to achieve the O/S and DB versions, using the Unicode conversion and another doing it seperately.
- (Notes: The colour of the servers is important as it reflects a change of hardware
- IA64 – Itanium Processor architecture
- X64 – X86 64Bit Processor architecture
- NUC – NonUnicode
- UC – Unicode)
Below is a table which details the agruements for and against each approach and you can quite clearly see a winner
There is one factor in all the of the discussions about options above that I have not dealt with, and that is the database size. Database size is a major driver as to which method of conversion you undertake, the larger the database and the longer it takes to convert – that is a fact. Not all databases are created equal, different vendors, different versions, different levels of administration all play their part in the Export/Import timings, but still data volume is the kicker – in this project a 4TB database had already defined the process as parallel as there was not a big enough window to perform the Unicode conversion as a serial task, the question now was just how much parallelisation did I need to use.
The next post will deal with the actual PoC process and what we found out running it.