hertenberger.co.za

It’s been many years since I last ran an SAP upgrade. In the days of 2.2F, upgrades were a lot of fun, took many days and required a bit of thinking. A seven day upgrade was a challenge and made you feel like you’d accomplished something! Nowadays, it’s a question of swapping DVD‘s and answering questions posed by the guided procedure. Of course, that’s all good and on the whole, the PREPARE and SAPUP programs perform admirably. Except, I’ve had a heck of a time with the Java runtime to allow me to use the Upgrade Assistant. Not only with the upgrades I’ve had the pleasure of piloting in the past two weeks, mind you. The same nonsense occurs during the installation and maintenance of the portal. It’s a bad reflection on the much-hyped write-once, run anywhere model the Java virtual machine was supposed to provide.

My overall experience with Java has hardly been positive. Even worse is the odd mood and glaring inconsistencies the software seems to show: so, for example, I am able to deploy a JRE version 1.6 (not recommended by SAP) to run the Upgrade Assistant during an upgrade of a 4.6C Oracle system on Windows 2003 to 4.7. The Upgrade Assistant works happily and there are no glitches. I used that version simply because I had no access to anything else. That same JRE fails to make the Upgrade Assistant function on a 4.6C MaxDB system on Windows 2003 that is a candidate for an upgrade to ECC 6. But, the recommended versions in the version range 1.4.2 refuse to work, too. In the case of 1.4.2.13 the Upgrade Assistant starts but throws an error almost straight away:

SAP note 941595 provides a link to a URL on the Sun site where a much older Java version can be downloaded. Why can’t SAP provide a tried and tested Java runtime or SDK in the upgrade pack? It’s incredibly frustrating to install and uninstall Java runtime components to try and get a non-critical software component up and running. As a command line fan I’m very happy to simply run all my upgrades with mode SCROLL:

It recaptures that authentic SAP upgrade mood. Who the hell needs a GUI for an upgrade in any case?

I’ve recently experienced the trials and tribulations of installing and upgrading a piece of software I’ve known for many years. Starting life as DDB4, MaxDB under the MySQL banner has gone through many hands and developers, and even more names. Developed by the University of Berlin under sponsorship from Nixdorf Computers, it transformed into Supra, Entire-SQL, Adabas D and then SAP DB. The software has has been open-sourced for a while and has been under the knife many, many times. And that shows.

A recent installation of SAP 4.6C on Windows 2003 64-bit went rather awry. Strangely, SAP 4.6C installed without issue on the default database version of its day, SAP DB 7.2.05. Even better, the subsequent upgrade of the database software completed without issue to SAP DB 7.3.04. Since I intended upgrading to ECC 6.0, I hoped to get everything running in the SYSWOW64 shell, then transferring to 64-bit later on. Everything went well until I hit the upgrade to SAP DB 7.4.3. That failed spectacularly, many times. The reason for my upgrade path is the unfortunate legacy of an application passed from vendor to vendor and developer to developer. You can’t simpy upgrade to the latest, but have to follow a complicated upgrade path. I tried many things, but could not get the 7.4.3 software installed or upgraded. SAP technical support eventually indicated they could not support my upgrade path – try the 32-bit route, they suggested.

The 32-bit installation of the same type as tried in the SYSWOW64 shell works flawlessly. But even here, there is a dangerous side effect that trapped me on the second system with a database sized just beyond a certain limit. To cater for a database restore, I ensured the target database was at least 120GB in size. Accidentally, my first successful installation ended up being in the region of 126.9GB. On the quality assurance system, I sized the database slightly larger: 129.3GB, to be precise. I don’t pick these numbers, but simply provide a MB size in case you were wondering…

Turns out anything beyond 128GB for a database segment or space is too large. But not for SAP DB versions 7.2.05 or 7.3.04. No: it’s too big for version 7.4.3 and causes the upgrade to fail yet again:

extracting: -rw-r–r–       443294 2004-08-24 20:46:41 runtime/jar/sapdbc.jar
checking unpacked archive… ok
installation of SAP DB Server finished successfully Tu, Aug 26, 2008 at 10:17:43

finding instance type…
starting release already known
migration strategy already known
running finalize check…
looking for domain user…
current database state is OFFLINE
checking parameters…
parameter check failed
cannot finish instance update for “SID”
current database state is OFFLINE
checking parameters…
parameter check failed
param_checkall
ERR
-24973,ERR_XPCHECK: param check failure/request
DATA_SIZE_0002  Constraint
17024000

On later versions, this error can be resolved by changing the value of a database parameter, thus:

dbmcli -d <DBSID> -u <dbm>,<dbm pass> param_directput VOLUMENO_BIT_COUNT 6

But of course, this parameter does not exist in 7.4.3. Thankfully I could simply restart the installation and select smaller dbspaces instead of backing up, resizing and then restoring.

It’s an important lesson for all user of open-source software: the cost of free software is not measured by it’s ease of acquisition, deployment or ability to customize its features. Instead, its real cost is often realized only when it may already be too late: it’s been deployed and the organization using it has become dependent on it.

This is an extreme case: the versions of SAP DB mentioned here have been out of maintenance for ages. Nonetheless, such software is still in active use, as my experience has taught me…

And don’t ever believe the hype that software featuring a higher version number will be better than an older one!

Until 128-bit hardware is developed and a 50TB Oracle database can be loaded into a server’s RAM, SAP is indicating its intended strategy regarding 64-bit hardware and Unicode support. All new SAP Netweaver releases from 2007 will be supporting Unicode environments only. Furthermore, due to the “problematic operation” of 32-bit servers, all new SAP Netweaver releases will require 64-bit hardware.

Converting a system to Unicode is not a huge issue. Conversion tools are available, and SAP is promising that it will be possible to convert systems to Unicode as a by-product of a release upgrade. I see the forced conversion to 64-bit environments a bit more of a problem. I know of numerous sites that have recently purchased new 32-bit hardware. Given that hardware is still considered a serious investment by most companies, the case for a platform change may not be easy to make. Conversions from 32-bit to 64-bit environments require migration activities to be carried out, depending on the existing database management system installed.

Oracle 10g, the grid database release, has been available for a while. In the SAP environment, its readiness has just been announced. DBA’s already saw some cool features being integrated in Oracle 9. In the past, Oracle has been a very robust database but has had its fair share of intricacies involving tuning, monitoring and allocating space.

The recommended upgrade path to Oracle 10g is from a source release of version 9.2. The new self-tuning and self-analysis tool sounds promising, as does segment shrinking. Within the Automatic Workload Repository (AWR), Oracle provides different options for analysing the database performance. The Automatic Database Diagnostic Monitor (ADDM) is able to create tuning recommendations automatically, based on the content of the AWR. This should provide a nice addition to the built-in Oracle monitoring functions within SAP. I assume that these will be replaced in time with the content of the AWR and output from the ADDM. Segment shrinking permits the DBA to reclaim unused space in tables and indexes without a reorganization. The operation may be performed with the database in an online state and without consuming additional space. There are some restrictions, primarily involving tables with RAW fields.

Online reorganizations are a fairly new feature. The DBA is able to reorganize the database while in an online state. The feature makes use of a shadow copy of the relevant tablespace or objects – the amount of space required can be fairly high, depending on the size of the object. At least this cuts down on downtimes, a typical reason many companies tend to shy away from Oracle database reorganizations.

Some Oracle 10g standard features are not officially supported within the SAP environment. The recycle bin feature is not be used. This does not physically purge elements and objects until a physical purge command has been issued. This presents both a security issue and a potential space waster, which is why SAP is probably not too keen on seeing it used.

For users of SAP considering the upgrade to Oracle 10g it will once again be important to ensure that patch levels, SAP release levels and operating system versions are matched to the requirements stipulated by SAP. Check the product availability matrix in the SAP Service Marketplace prior to considering the upgrade.

Why not get your own copy to play around with in the meantime. Directly from Oracle.

So: your SAP system is performing poorly, to say the least…so bad in fact, that overall IO wait times seen in the snapshot data from ST04 on your database disks is around 817905973ms! Yep – I’ve never seen anything like that myself…

Where to start looking? Any trace, performance examination or tuning attempt leads to the conclusion that disk IO is through the roof and SQL statements are poorly optimized. What if the database is external, sitting on a SAN, such as an EMC²? Take heed! The position of partitions on the SAN is critical to performance, and not restricted to EMC² either. To prevent the disks from going crazy trying to read the data, it is imperative that the starting offset of the partition on the SAN be 32,768 and not the defaut value 32,256.

Windows Server as the OS of course Check on the database server by launching WINMSD, then go to Components, then Storage, then Drives. The starting offset is indicated for each drive letter. If it’s the wrong value, the database needs to be backed up, the partition re-created with the correct offset and the database restored.

Get more info in SAP’s OSS note number 886337 and EMC²’s engineering white paper on using diskpar.