Below is an overview of the tasks associated with an SAP NW731 system copy for Java on Windows with MS SQL Server (see the ABAP tasks here). Essentially, this is what I document when I go through the process:
Current Base Details (Kernel version etc)
Current Profile Files
Source Server IDs (Java node IDs)
Current J2EE License
Current SSL Certificates (export PSEs)
Current Database Files
Source Database Files
Source Disk Usage
Target Disk Capacity
Current SQL Server Version
Current Windows Hotfixes
Detach Old Target Database
Delete Old Database Files
Create Additional Data File Locations
Restore Database as Target
Rename Logical Files (MS SQL Server)
Deploy SWPM
Start Java SCS
Launch SWPM
Follow standard system copy doc:
Adjust server Ids (Java node Ids)
Restart Central Instance
Remove Old SSL Key Store Views
Re-Generate Certificates
Re-Configure SSO
Database Stats Collection
Configure & Schedule Database Backup
Adjust Default Database Connection for <sid>adm User
Post Process Tasks
Release VM Snapshot (or send tapes offsite)
Adjust AS-Java Instance VM Settings (de-tune memory)
There is a small bug in the ABAP code when registering a SAP system to be monitored in a central system (e.g. Solution Manager) in transaction RZ21. This was found on a Solution Manager 7.1 system.
The scenario is: You try and register a remote monitor entry in RZ21, you enter the message server details of the system, the password for the CSMREG and the <sid>adm user, then click Save. The screen gets to the "generating logical ports..." section but you notice that it mentions a non-existent instance number for the system it's generating the ports for e.g. instance 00, instead of 01. At the end of the process, you get an error about invalid XML or an XML error in the error message panel.
The reason: If the SAP system to be monitored, has an instance which is using a HTTP port that is less than 3 digits (e.g. port 80), then the ABAP code in the Solution Manager, incorrectly determines the instance number of the instance to be “00”.
To get around the issue, the ABAP debugger had to be used to manually adjust the instance number prior to it being saved.
Create a breakpoint in the code as follows. Use SE38 to display the source of include LSALWS_CONFIGF01:
Image may be NSFW. Clik here to view.
Scroll to line 1276:
Image may be NSFW. Clik here to view.
Click to add a new session breakpoint:
Image may be NSFW. Clik here to view.
Image may be NSFW. Clik here to view.
Then, before you click “Save” in RZ21 after entering the message server details and passwords, type “/h” into the command bar:
Image may be NSFW. Clik here to view.
Then click Save in RZ21. Once the breakpoint line is reached, the debugger will be launched and displayed. Change the value for the variable “ws_instance_list-inst” from “00” to the correct instance values (in our case it was “01”), then continue the execution from the debugger: and the entries will be created correctly.
For systems with multiple instances, you need to change both instances during the loop so ensure that you do not remove the session breakpoint until the save process is completed.
If you have tried to register the system in RZ21 before, and it failed, there may be an invalid entry now present in the Topology view in RZ21. Simply delete the invalid segment from RZ21.
During the SAP HANA install, you get an error in the setup.glf log file for hdbnsutil failing with return code 6 (signal 6).
The error could be caused by the call of "hdbnsutil -initTopology" which creates the system and the initial license. An out of memory error could occur if this is a VM with less than ~5GB of RAM allocated (hdbnsutil tries to allocate 4GB of memory).
You can check if this is the cause of the error, as hdbnsutil will produce a trace dump in the directory "/usr/sap/<SID>/HDB<##>/<host>/trace/". Check the trace files "nameserver_<host>.*.*.trc" for the error "OUT OF MEMORY". If this is the case, increase the memory to the VM and restart.
When you come to use SWPM for the first time to copy a SAP system which has a virtual hostname defined and used, be aware that the SWPM has in-built checks to ensure that the Windows registry is correctly configured according to SAP note 1564275.
If you've not fully implemented the note configuration in the Windows registry, even if you're using the "SAPINST_USE_HOSTNAME=<hostname>" SAPInst.exe parameter, the SWPM will show an error and exit.
My specific setup was missing the DisableStrictNameChecking setting. After adding this into the registry, I was able to launch SWPM.
Scenario: During a SAP NW731 system copy, the SWPM prompts you to set the rdisp/msserv and rdisp/msserv_internal parameters in the SCS instance profile.
Image may be NSFW. Clik here to view.
The problem is, these are already set in the SCS instance profile. You can clearly see them there.
The solution is to ensure that the same parameters and values are also set in the DEFAULT.pfl profile file too. This is not so clear, but it is mentioned in SAP note 1421005.
As an example, a non-Unicode SAP table (DBTABLOG) in an Oracle 11gR2 database (character set ALE32UTF16) without any Oracle compression, was ~80GB in total size (sum of table segments, excluding indexes).
Once this was exported to disk using R3load export, in preparation for a conversion to Unicode, it occupied ~70GB in the data files (DBTABLOG.00*).
Once this was re-imported into a new Oracle 11gR2 database with character set UTF8 (again, no compression) it occupied ~90GB (sum of segments, excluding indexes).
You must remember that this table is specific in it's usage. It doesn't have any rows deleted from it, it's append only, so it should grow in a nice uniform manner and not be fragmented. There may be other tables where you could save space. If you notice that your R3load export files are significantly different in size compared to the Oracle size, then you could have some serious fragmentation inside your Oracle database.
From NetWeaver 7.0 onwards, you now need to use the SAP Software Provisioning Manager (SWPM) to perform system copies. As an example, a production MS SQL Server database PX1 is restored from backup onto a training system database server. After the restore is completed, you now have your TX1 database refreshed, but the schema inside the database is still the source system schema and there are post-copy tasks to perform. What media is needed? You will need the following media:
SWPM SAR file.
The 700 and 720 SL-Controller file updates are not needed for system copies (unless you are installing/re-installing a Java AS).
You need both the 720_EXT unicode and non-unicode Kernels for SWPM (they are specific Kernels located in the SWDC under the NetWeaver download location. They specifically say "... for SWPM"). You will need the UC kernel even if your system is NUC!
Image may be NSFW. Clik here to view.
Any GOTCHAS?
You need the source system DDIC password for 000.
You need the password for the <sid>adm user.
You need the password for the SAPService<SID> (Windows) user.
The software media is around 4GB in size!
The SWPM performs approximately the following tasks (I've added my own comments) taken from the detailed timings report at the end of a run. I thought this might be useful to anyone new to the process:
Update System DLLs (not sure what DLLs, maybe VC++ Redist)
Re-Create users for SAP system (in database?)
Re-Install common system files (maybe SAPMMC files, HostAgent)
Configure database client (SNAC is already installed? maybe install MS JAVA JDBC JARs)
Cleanup of temp database objects.
Create/modify system database schema.
Migrate objects to new schema.
Delete old schema.
Set compatibility level for databases (sets to compatibility 100 for DB, tempdb, model, master)
Create SAP stored procedures.
Any MS SQL Server specific tasks (set PAGE_VERIFY to CHECKSUM, set AUTO_UPDATE_STATISTICS_ASYNC to ON, set ANSI_NULLS to ON, set AUTO_UPDATE_STATISTICS to ON, set AUTO_CREATE_STATISTICS to ON, configures FILESTREAM, reconfigures parallelism and min and max memory settings, enables xp_cmdshell.
Grant database access for the <sid>adm user, SAPService<sid> user and SAP_<SID>_LocalAdmin group.
Configure database parameters.
Perform post-load activities.
Check DDIC password (client 000, if you don't have it right it prompts you to re-enter it here).
At the end of the process, the schema is migrated and the system is ready to use. There are some additional database specific tasks to perform, you need to check the SAP notes for your specific database instance. See SAP Note 888210 - "NW 7.**: System copy (supplementary note)"
The SAP BWA (BW Accelerator) is based on the TRex search service and uses dedicated hardware to provide an additional in-memory index search capability for an existing SAP BW system. NOTE: This is not to be confused with the SAP HANA DB, which is also in-memory, except that HANA is a more advanced and fully rounded product and not related to TRex.
Scenario: You may know there is a BWA connected to your BW system, but you don't know where it is and what version it is. You may need to consider this information in preparation for an upgrade. The BWA details can be seen from the BW system via transaction TREXADMIN. The "Summary" tab shows all the revision details and the make and model of the dedicated hardware:
Image may be NSFW. Clik here to view.
Additional version information can be seen on the "Version" tab, you can also see any additional load balancing nodes in the TRex landscape:
Image may be NSFW. Clik here to view.
Connectivity to TRex is performed either via RFC server on the TRex server (BWA 700) or via the ICM (BWA 720+). The TRex Web Service which can be accessed via "http://<trex server>:3xx05/TREX". The "Connectivity" tab allows you to perform connectivity tests for RFC and HTTP to the BIA. For RFC based connections, once registered at the gateway, you can see the detail in transaction SMGW (select "Goto -> Logged on Clients"):
Image may be NSFW. Clik here to view.
You can see the TRex connections based on the "TP Name" column:
Image may be NSFW. Clik here to view.
For ICM based connections, you will see the HTTP requests going out via the ICM in transaction SMICM. For SAP notes searches, the component for the BWA is BC-TRX-BIA.
Some companies have additional security policies that remove the Telnet application from the local desktop PCs. This can prove difficult for SAP BASIS people trying to test if a specific network port is reachable, since Telnet is a perfect way of testing if a server port is accessible, or being blocked by a firewall. Instead, you can use the NIPING tool (Network Interface Ping) supplied with the SAP Frontend installation on the desktop PC.
Check if you have NIPING.exe, it should exist in the default install location: "C:\Program Files\SAP\FrontEnd\SAPgui\".
You have to call NIPING from a command prompt:
C:> cd C:\Program Files\SAP\FrontEnd\SAPgui\ There are two command line options that are useful when calling NIPING. The command line option "-R" tells NIPING to attempt a RAW TCP connection. Option "-P" specifies that NIPING should option slightly more detail.
If you need to test if a network port is available, you need to use the RAW option. You don't care what transport layer protocol is required (SMTP, HTTP, Telnet, SSH), you just want it to try and open a bare TCP connection to the specified port and see what happens.
To use NIPING with the RAW option:
> niping -H <dest host> -S <dest port> -R -P You will get some fairly detailed output. What you are looking for is a return code (RC) of "-6" and "ERROR connection to partner 'xxx.xxx.xxx.xxx:pppp' broken".
The RC of "-6" indicates that NIPING was able to open the TCP connection (NIPCONNECT) successfully, but it was not able to receive (NILREAD) because the server closed the connection when we didn't send any information (it was a raw connection).
If you receive an RC of "-10" and "ERROR partner xxx.xxx.xxx.xxx:pppp not reached" this indicates that NIPING was not able to even establish a basic TCP connection (NIPCONNECT) to the server host and port. You may not have an network route to the server, the server IP may be invalid, the port may not be listening on the server, a firewall may be blocking you and many other reasons.
If you are simply trying to connect to a known SAP system dispatcher port (for SAP GUI connections), then using NIPING without the RAW option will perform an RFC connection to the SAP system dispatcher, if possible:
> niping -H <dest host> -S 32<SAP_sys_id> When you use NIPING without the RAW option, it will return success ("Connect to server o.k.") if it can successfully connect to the SAP system dispatcher. It will always complain about "bytes_written <> bytes_read", so ignore this error.
You should note that connecting to the SAP ABAP message server (36xx) will return a "ERRORconnection to partner xxx.xxx.xxx.xxx:pppp broken" and RC "-6" (just like a RAW connection) if it was successful. The reason is that this is not a straight RFC connection that supports NIPING. It's meant to hand-off to a specific dispatcher or other tasks, but not ping.
During a system copy, you are advised in SAP note 816861 to migrate the entries in the SAP Secure Store through transaction SECSTORE or report RSECADMIN. When you run those transactions, you only see message SECSTORE031 for the CL_HTTP_SERVER_NET item which uses HMAC (Message Authentication Code).
Image may be NSFW. Clik here to view.
If you are simply performing a system copy to an existing system (system refresh) then you do not need to migrate the system just for the CL_HTTP_SERVER_NET item. As per SAP note 1908221, you can just delete the item CL_HTTP_SERVER_NET from SECSTORE and it will be re-created when the system next starts up.
Scenario: You want to know which version of Solution Manager you are currently using. The problem with Solution Manager, is that it has been through the SAP makeover factory a couple of times and been given new names. Not only this, but like other SAP products, the version of Solution Manager may not actually be easily discernable. SAP note 394616 - "Release strategy for SAP Solution Manager", provides the answer. From within your Solution Manager system, select "System -> Status" from the SAP GUI menu, and check for the version of the "ST" component:
Image may be NSFW. Clik here to view.
In the popup, you will see the general description: TIP: If you hover the mouse over the text field, you can see the whole string, or you can scroll left and right when the cursor is inside the field.
Image may be NSFW. Clik here to view.
If you click the magnifying glass icon, you can see the full system component list and versions:
Image may be NSFW. Clik here to view.
You are looking for the component "ST" in the list:
Image may be NSFW. Clik here to view.
This can be compared to the contents of the SAP note 394616 mentioned earlier. As the above example shows, ST version 400 patch 24 = SAP Solution Manager 7.0 EHP 1. SAP Solution Manager 7.1 on HANA ST Release ST 712 NW Release NW 7.4 SAP Solution Manager 7.1
ST Release ST 710 NW Release NW 7.0 EHP 2 SAP Solution Manager 7.0 EHP 1
ST Release ST 400 NW Release NW 7.0 EHP 1 SAP Solution Manager 7.0
ST Release ST 400 NW Release NW 7.0 SAP Solution Manager 3.2
ST Release ST 320 WebAS Release WAS 6.20 SAP Solution Manager 3.1
After working as a BASIS guy for many years, I've come to the conclusion that SAP don't want to provide an easy experience when analysing SAP notes. Compared to Oracle's MYOS site, SAP have a long way to go. For SAP notes, it takes time find them, you go round in circles and you forget what you've read and what you haven't. It costs me a lot of time on my projects, so I thought there must be a better way.
I decided to invest some time. I taught myself how to write a Google Chrome Extension and created the FREEPower Notes Searcher extension for Google Chrome.
It's just gone live on the Google Chrome App Store today! Very exciting!
I hope it makes you more productive with your work. It definitely has made me more productive and I can produce better documentation, quicker! This is great news for my current and potential clients.
Whilst investigating a performance issue on an Oracle 10.2.0.5 database running on Solaris 10, I had to do a little digging to discover exactly how asynchronous I/O is implemented within Oracle when the database is using the UFS filesystem.
It was not as straightforward as i thought, because I had to start from the beginning and not trust any current Oracle settings. For example, FILESYSTEMIO_OPTIONS was set to "ASYNCH" in the spfile. This would normally indicate that a DBA has specifically determined that ASYNCH I/O is possible and that they do not want to use DIRECTIO (or concurrent I/O).
Yet, reading the SAP notes, you would think that this is a moot point. SAP note 830576 “Parameter recommendations for Oracle 10g” v227 clearly states that Oracle 10.2 on Solaris with UFS filesystems, supports asynchronous I/O, so therefore set the FILESYSTEMIO_OPTIONS to "SETALL".
However, if you have access to "My Oracle Support" you can check Oracle document "SOLARIS: Asynchronous I/O (AIO) on Solaris (SPARC) servers (Doc ID 48769.1)" which explains that, in Solaris with UFS, Oracle does not actually perform asynchronous I/O at the kernel (Solaris) level. Instead, Solaris simulates AIO by performing parallel writes (calls pwrite() ) but to Oracle it still looks and feels like KAIO. So, the details in the SAP note are not exactly accurate. AIO is not supported in Solaris, but is simulated. Also, the simulation is just issuing more parallel I/O requests.
If your disk sub-system is slow, it's still going to be slow, but Oracle writes might be slightly faster if you handle/tune for more parallel requests at the storage layer.
As far as I know there is no single SAP note that lists all Kernel releases. However, when problems with language related functions appear, they are documented on SAP note 447519 which generally seems to include all Kernel releases.
If you have a SAP Java stack (either pure or part of a dual stack), you should never ever use the J2EE_ADMIN account (or any other high privileged account) to access the SLD. This is because on most SAP systems, the standard out-of-the-box installation and configuration for the SLD does not use SSL for communications to/from the SLD.
If you use the J2EE_ADMIN account to access the SLD, then each authentication request that the SLD issues to the client system (the SAP system querying or updating the SLD) will be sent unencrypted. If the client system responds with the J2EE_ADMIN account username and password (if you put this in the NWA or RZ70) then the username and password are simply combined into a standard HTTP BASIC authentication response (http://www.w3.org/Protocols/HTTP/1.0/spec.html#BasicAA).
Essentially the username (J2EE_ADMIN) and password are combined into a string like this: <user>:<password> and then encoded (not encrypted) with BASE64. This will then be sent in the clear (unencrypted) across the network to the SLD. If you have Java stack full HTTP tracing turned on, you can see the authentication requests and responses and therefore see the password. If you have a network packet sniffer installed, then you can see the authentication requests and responses and therefore see the password.
If you have a SAP PI system, you should really consider using SSL (HTTPS) for the SLD traffic. Since it is possible to completely bring down a SAP PI system by causing mayhem in the SLD.
Scenario: You have a SQL Server database for your SAP system, and you know that right clicking the database server name in SQL Server Management Studio, selecting "Properties" and then "Memory", will show you the SQL Server memory settings, but you want to know how you can see/change the same detail in SAP...
Image may be NSFW. Clik here to view.
Image may be NSFW. Clik here to view.
In SAP, you can use transaction ST04 to see the SQL Server database settings. The memory details are visible in the "Overview" screen. You will see the "Current Memory MB" equals the amount of memory allocated to SQL Server, and if the "Min server memory" and "Max server memory" settings have been set equal (recommended by SAP), then the overview screen will show "FIXED" for the "SQL Memory Setting":
Image may be NSFW. Clik here to view.
It is possible to modify this setting directly from ST04. You will need to expand the "Diagnostics" branch and then double click "SQL Command Editor":
Image may be NSFW. Clik here to view.
On the right hand side, enter the SQL Server commands to resize the memory (notice that these are slightly different to the SQL statements when using them in SSMS):
If you noticed, I didn't change the "Min" memory setting, only the "Max". When I check in the "Performance -> Overview" screen in ST04, I can now see that the "Current Memory MB" setting has not changed, but the "SQL Memory Setting" is now showing "RANGE":
Image may be NSFW. Clik here to view.
Now if I use the SQL Command Editor to also change the "Min" memory, we will see the ST04 overview screen update:
Image may be NSFW. Clik here to view.
exec sp_configure 'show advanced options', 1 RECONFIGURE exec sp_configure 'max server memory', 4096 exec sp_configure 'min server memory', 4096 RECONFIGURE Image may be NSFW. Clik here to view.
And the overview screen:
Image may be NSFW. Clik here to view.
Well, we're at "FIXED" again, but the amount of memory has not changed. Yet in SSMS, I can see the allocation has changed:
Image may be NSFW. Clik here to view.
This is a weird, because the Microsoft documentation for SQL Server 2008R2 (my version) says that the setting should take effect straight away. I guess there's something within the ST04 screen that doesn't update. There is another way... You can use the "Configuration -> Overview" screen and the "Configuration Options" tab to see both the Min and Max memory settings. As per out change, these correctly reflect the current memory settings:
Image may be NSFW. Clik here to view.
WARNING: You should be aware that during testing, I was able to set the Min memory value higher than the Max memory value in ST04. I was then unable to change this through ST04, as the store procedures just produced errors and refused to let me change the values. In the end I had to change the Max value using SSMS.
Within the SAP St03 transaction, the analysis view "Wait Event Analysis -> IO Redo Log Per Hour" or "Redo Log Switches" (from SAPKB70029 onwards), is able to show you the Oracle redo log switch measure. Image may be NSFW. Clik here to view. You will need to adjust the "Minimum Time Between Switches[sec]" and "Maximum Time Between Switches [sec]" values, then click the refresh button. The results tell you in what hour period, the number of times a redo log switch was performed where the time between the switches was within your defined range. As an example, the screen shot above shows that on 29-11-2013 between 04:00 and 05:00, a redo log switch occurred on only 1 occasion where the time between one log switch and another was within 120 seconds (2 minutes). It's difficult to say if too many log switches is an actual problem for your specific database, but I would tend to investigate any database where the logs are switching on more than a couple of occasions a day, within 60 seconds.
Scenario: You want to prototype something and you don't have the hardware available for a new prototype HANA database. Instead, you can use the power of a virtual machine to get a HANA SPS07 database up and running in less than 30 minutes. Well, it was supposed to be 30 minutes, and it sure can be 30 minutes, providing you have the right equipment to hand. As I found out, working on a slow disk, limited CPU system, extended this to 2 hours from start to finish. Here's how...
What you'll need: - SAP HANA In Memory DB 1.0 SPS07 install media from SAP Software Download Centre. This is media ID 51047423. - The SUSE Linux for SAP v11 sp02 or sp03 install media (ISO). - A valid license for the HANA database (platform edition or enterprise edition). - SAP HANA Studio rev 70 installed on a PC which can access the virtual HANA server you're going to create (the Studio install media is contained within the HANA install media DVD, or you can download it separately). - A host machine to host the virtual machine. You need at least 20GB of RAM, although if you configure your pagefile (in Windows) on SSD or flash, you could get away with 16GB (I did !!!).
What we're going to do: - We'll create a basic SUSE Linux for SAP virtual machine. You can use any host OS, I'm using Windows 7 64bit. - Because most people are using VMs to maximise infrastructure, we'll go through a couple of steps to really reduce the O/S memory footprint (we disable X11 as one of these steps). We get this whole thing running in less than 16GB of RAM in the end. - We'll install a basic HANA database. - We disable the XS-Engine (saving a lot of memory) which you don't have to do if you absolutely need it. The XS-Engine is a lightweight application server for hosting the next generation HANA based APPS.
START THE CLOCK!
Create your basic VM for SUSE Enterprise Linux (I'm using SUSE Linux for SAP SP2). It will need the following resources: - More than 16GB of RAM (preferably 24GB) on the physical host machine . - 8GB of disk for the O/S. - 50GB of disk for the basic HANA DB with nothing in it, plus the installed software. - 20GB of disk on the physical host for swapping (if you don't have 20GB of RAM). - 2 CPUs if you can spare the cores. - A hostname and fully qualified domain name. - Some form of networking (use "Bridged" if you need to access this across the network).
Let's create the VM and set the CDROM to point to the SUSE Linux SP2 install DVD ISO file:
Image may be NSFW. Clik here to view.
Confirm the VM full name, your username and your preferred password (for the username and for root):
Image may be NSFW. Clik here to view.
Set the location to store your VM files:
Image may be NSFW. Clik here to view.
Set the initial hard disk to have 8GB and store it in one big file (it's up to you really):
Image may be NSFW. Clik here to view.
Now customise the hardware:
Image may be NSFW. Clik here to view.
Set the RAM to 20GB or more (you really need 24GB of RAM, but I have only 16GB and will be ready for some serious swapping). At a minimum the VM should have 18GB of RAM for day-to-day running:
Image may be NSFW. Clik here to view.
Give the VM at least 2 cores:
Image may be NSFW. Clik here to view.
Use bridged networking if you need to access over the network, but only if you have DHCP enabled or you're a network guru:
Image may be NSFW. Clik here to view.
Start the VM.
We're off. The SUSE install took 12.5 minutes in my testing on a core i5 (unfortunately only 3rd gen :-( ):
Image may be NSFW. Clik here to view.
Oh look, it reckons that we have 12mins 19 seconds left until completed:
Image may be NSFW. Clik here to view.
Boom, SUSE is up!
Image may be NSFW. Clik here to view.
Shutdown the VM again so that we can add the second hard disk:
Image may be NSFW. Clik here to view.
Image may be NSFW. Clik here to view. Image may be NSFW. Clik here to view.
It's SCSI as recommended:
Image may be NSFW. Clik here to view.
We set it to max out at 50GB (set yours however large you think you will need it, but we will create this in a volume group so you can always add more hard disks and just expand the volume group in SUSE):
Image may be NSFW. Clik here to view.
NOTE: If you're going to be moving this VM around using USB sticks, you may want to choose the "Split..." option so that the files might fit.
Give the VMDK a file name (I've added "HANADB" so I can potentially plug and play this disk to other VMs):
Image may be NSFW. Clik here to view.
Also re-add the CDROM drive (mine went missing after the install, probably due to VMWare player's Easy Install process):
Image may be NSFW. Clik here to view.
Configure the CDROM to point to the ISO for the SUSE install DVD again. Start the VM again:
Image may be NSFW. Clik here to view.
Notice the Kernel version we have is 3.0.13-0.27:
Image may be NSFW. Clik here to view.
From the bottom bar in SUSE, start YAST and select the "Network Settings" item:
Image may be NSFW. Clik here to view.
Disable IPv6 on the "Global Options" tab:
Image may be NSFW. Clik here to view.
On the hostname tab set the hostname and FQDN:
Image may be NSFW. Clik here to view.
Apply those changes and quit from YAST. Right click the desktop and open a Terminal:
Image may be NSFW. Clik here to view.
Add your specific IP address and hostname (fqdn) plus the short hostname to the /etc/hosts file using vi:
Image may be NSFW. Clik here to view.
Save the changes to the file and quit vi.
Reboot the HANA VM from the terminal using "shutdown -r now". Once it comes back up, you need to check the hostname resolution:
Image may be NSFW. Clik here to view.
According to the HANA installation guide I'm following, we need to apply some recommended settings following SAP note 1824819:
Image may be NSFW. Clik here to view.
So we run the command to disable the transparent huge pages:
# echo never > /sys/kernel/mm/transparent_hugepage/enabled
I checked the C-state and it was fine on my Intel CPU.
We're not using XFS so I don't need to bother with the rest, I don't want to patch my GlibC, but feel free to if you wish.
15 MINUTES HAVE NOW ELAPSED!
A quick recap, we should have working SUSE VM, it should be booted and you should have the SUSE DVD loaded in the virtual CDROM.
Open a new Terminal window:
Image may be NSFW. Clik here to view.
Now install the following Java 1.6 packages from the source distribution (these are part of the HANA install guide for sp07, page 15):
# cd /media/SLE-11-SP2-SAP-DVD-x86_640025/suse/x86_64
# rpm -i --nodeps java-1_6_0-ibm-*
The rest of the requirements are already installed in SUSE EL 11 sp2 for SAP.
Now we create the volume group for the HANA database and software. First check which disk you're using for the O/S:
Image may be NSFW. Clik here to view.
So, I'm using "sda" as my primary disk. This means that "sdb" will be my HANA disk . WARNING: Adjust the commands below to the finding above, so you use the correct unused disk and don't overwrite your root disk.
Create the new partition on the disk:
# fdisk /dev/<your disk device e.g. sdb>
Then enter:
n <return> p <return> 1 <return> <return> <return> t <return> 1 <return> 8e <return> w <return>
Now we've got somewhere to create our HANA database and put the software. To perform the HANA install, I've converted my downloaded HANA install media into an ISO file that I can simply mount as a CD/DVD into the VMware tool. Instead of this method, you could alternatively use the Shared Folders capability and simply extract the file to your local PC, sharing the directory location through VMware to the guest O/S. The outcome will be the same.
Mount the ISO file (HANA install media, from which I've created an ISO for ease of use). You can do this by presenting the ISO file as the virtual CDROM from within VMWare.
Open the properties for the virtual machine and ensure that you select the CDROM device:
Image may be NSFW. Clik here to view.
On the right-hand side, enable the device to be connected and powered on, then browse for the location of the ISO file on your PC:
Image may be NSFW. Clik here to view.
Apply the settings to the VM.
Prior to starting the install, we can reduce our memory footprint of the O/S by over 1GB. Use vi to change the file /etc/inittab so that the default runlevel is 3 (no X-windows):
Image may be NSFW. Clik here to view.
Also, disable 4 services that are more than likely not needed and just consume memory:
Disable VMware thin printing:
# chkconfig vmware-tools-thinprint off
Disable Linux printing:
# chkconfig cups off
Disable Linux auditing:
# chkconfig auditd off
Disable Linux eMail SMTP daemon:
# chkconfig postfix off
Disable sound:
# chkconfig alsasound off
Disable SMBFS / CIFS:
# chkconfig smbfs off
Disable NFS ( you might need it...):
# chkconfig nfs off
Disable splash screen:
# chkconfig splash off
Disable the Machine Check Events Logging capture:
# chkconfig mcelog off
Double check the IP address of your VM:
# ifconfig | grep inet
Image may be NSFW. Clik here to view.
Your IP address should be listed (you can see mine is 192.168.174.129). If you don't have one, then your VM is not quite setup correctly in the VMWare properties or your networking configuration is not correct, or you don't have a DHCP server on your local network, or your network security is preventing your VM from registering it's MAC address. It's complex.
Assuming that you have an IP address, check that you can connect to the SSH server in your VM using PUTTY :
Image may be NSFW. Clik here to view.
Enter the IP address of your VM server:
Image may be NSFW. Clik here to view.
Log into the server as root:
Image may be NSFW. Clik here to view.
From this point onwards, it is advisable to use the PUTTY client tool to connect, as this provides a more feature rich access to your server environment, than the basic VMWare console connection. You now need to restart the virtual server:
# shutdown -r now
Once the server is back, re-connect with PUTTY. We will not use the GUI for installing the HANA system (hdblcmgui), because this takes more time and more memory away from our basic requirement of a HANA DB. Mount the cdrom inside the SUSE O/S:
# mount /dev/cdrom /media
Change to the install location inside the VM and then run the hdbinst tool (this is the lowest common denominator regarding HDB installation):
You will be prompted for certain pieces of information. Below is what was entered: Installation Path: /hana/shared System ID: H10 Instance Number: 10 System Administrator Password: hanahana System Administrator Home Dir: /usr/sap/H10/home System Administrator ID: 10001 System Administrator Shell: /bin/sh Data Volumes: /hana/data/H10 Log Volumes: /hana/log/H10 Database SYSTEM user password: Hanahana1 Restart instance after reboot: N
Installation will begin:
Image may be NSFW. Clik here to view.
My HANA DB install took approximately 1 hour 20 minutes on a Core i5 with 16GB RAM, 5400rpm HDD (encrypted) plus a large pagefile (not encrypted):
Image may be NSFW. Clik here to view.
****** OPTIONAL ******** After the install completed, I then followed SAP note 1697613 to remove the XS-Engine from the landscape to reduce the memory footprint even further: From HANA Studio, right click the system and launch the SQL Console:
Image may be NSFW. Clik here to view.
Run the following SQL statements (changing the host name accordingly):
select host from m_services where service_name = 'xsengine'
select VOLUME_ID from m_volumes where service_name = 'xsengine'
ALTER SYSTEM ALTER CONFIGURATION ('daemon.ini', 'host', 'hana01') UNSET ('xsengine','instances') WITH RECONFIGURE
ALTER SYSTEM ALTER CONFIGURATION ('topology.ini', 'system') UNSET ('/host/hana01', 'xsengine') WITH RECONFIGURE
NOTE: Change the value "<NUM>" below to be what is reported as the volume number in the second SQL statement above.
ALTER SYSTEM ALTER CONFIGURATION ('topology.ini', 'system') UNSET ('/volumes', '<NUM>') WITH RECONFIGURE
The XS-Engine process will disappear. You can now restart the instance and then restart the HANA instance using HANA Studio.
****************
This completes the HANA DB install. At the end of this process you should have a running HANA database in which you can execute queries. It's possible you can reduce the VM memory allocation to 16GB and the HANA instance will still start (if you remove the XS-Engine). You should note that we don't have the HANA Lifecycle Manager installed. You'll need to complete this if you want to patch this instance. However, for 15mins work, you can re-install!
NOTE: Consider SAP note SAP Note 1801227 "Change Time Zone if SID is not changed via Config. Tool" v4. The default timezone for the HANA database doesn't appear to be set correctly. You can also check/change the Linux O/S timezone in file "/etc/sysconfig/clock".
Scenario: You have a SAP Java stack which is hosting either some SAP components/modules, or it's hosting your own custom Java code. You would like to perform a full HTTP trace so that you can see the HTTP headers and returned content during a HTTP session between your browser and the SAP HTTP Server. You also wish to see timings for the processing time of the response. Following SAP note "724719 - How to enable HTTP tracing in the SAP J2EE Engine 6.40/7.0" connect into the SAP Netweaver Administrator main web page as J2EE_ADMIN: Image may be NSFW. Clik here to view. On the left-hand side, select "System Properties": Image may be NSFW. Clik here to view. Select the dispatcher item under "<SID> -> Instance -> Dispatcher": Image may be NSFW. Clik here to view. On the Services tab, select "http": Image may be NSFW. Clik here to view. In the "Properties" tab at the bottom, select "HttpTrace" and click the "Modify" button: Image may be NSFW. Clik here to view. Image may be NSFW. Clik here to view. Now change the trace setting to the following: Image may be NSFW. Clik here to view. The possible values are described in the SAP note as: enable Using this option will cause the whole requests/responses to be written enableHeaders Using this option will cause only the headers of each request/response to be written enableHex Using this option will cause the whole requests/responses to be written in a 16-column hexadecimal format. This option is valid for J2EE Engine SP10 or higher enableHexHeaders Using this option will cause only the headers of each request/response to be written in a 16-column hexadecimal format. This option is valid for J2EE Engine SP10 or higher The SAP note also recommends to set the property HttpTraceTime, to "true". This is described further in SAP note "972540 - Tracing dispatcher and server response times". Since you would only get the dispatcher processing time, you should also set the server trace property as described in the above note, to allow you to see the server processing time:
"1) dispatcher + server processing time trace in http access log - On the dispatcher enable Http Provider#s property #HttpTraceTime# - On the servers enable Http Provider#s property #LogResponseTime# Then messages in the httpaccess response file will contain additional fields d[...] and c[...] where d is dispatcher and server processing time and c is client id. 2) additional traces - if the request is processed for more than XX seconds - there is a new Http Provider#s property on the server # #TraceResponseTimeAbove# - if its value is -1 then there will be no additional traces - if its value is >-1 (the value represents the response time in ms) then additional traces will be written in the default trace file only for these requests which response time is >= property#s value - on the servers put the log severity for HttpProvider service to DEBUG"
Once you have enabled the tracing, no restart of the Java stack is required. It is activate immediately. Simply check the trace output file /usr/sap/<SID>/<instance>/j2ee/cluster/dispatcher/log/services/http/req_resp.trc (for NW731+) using operating system level file viewers (or AL11 in an ABAP stack). For information, you should be aware of the HTTP 1.1 status codes, so you know what to look for if you are tracing an authorisation error (HTTP authorisation) or some other HTTP related issue http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html .
