Increased installation duration for SAP BI 4.0 SP07 & FP02 on SuSE Linux Enterprise 11

[Former Member]

Dear all,

On a virtual machine system with the following specifications:

• O/S: SUSE Linux Enterprise Server 11 (x86_64 - VERSION = 11 - PATCHLEVEL= 0)
• CPU: 12 x Intel(R) Xeon(R) CPU E7-L8867  @ 2.13GHz
• RAM: 26,626,416 kB
• Java:"1.6.0_37" - Java(TM) SE Runtime Environment (build 6.1.044) - SAP Java Server VM (build 6.1.044 21.1-b02, Nov  2 2012 00:58:44 - 61_REL - optU - linux amd64 - 6 - bas2:182728 (mixed mode))
• Repository database: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit (Exadata)
• Kernel Parameters: configured according to the installation guide

,we've encountered increased installation duration while upgrading from SAP BI Platforms 4.0 SP05 FP05 to SP07 + SP07-FP02. For example the installation of SP07 lasted ~17hours.

In addition, we've monitored the system with customers' system administrators while installing SP07 and we didn't see something that could explain this behavior (e.g. increased cpu or i/o usage). After examining the logs we've identified the following processes which sloweddown the installation (notice the 3min delay while removing or writing a registry key).

--

-- REMOVE REGISTRY KEY

--

23:49:17.651 Running action: RemoveFromRegistry

(platform.services.jobprocessing.programschedulingservice-4.0-core-64,14.0.5.882)

<0, 3, 0>

23:49:17.651   Action args:

23:49:17.651       BinDir32:

[INSTALLDIR]sap_bobj/enterprise_xi40/linux_x86/

23:49:17.651       BinDir64:

[INSTALLDIR]sap_bobj/enterprise_xi40/linux_x64/

23:49:17.651          DUDir: [$du.dir]

23:49:17.652     ObjectModel: 64

23:49:17.652          Props: INSTALLDIR="[INSTALLDIR]"

23:49:17.652        RootDir: [INSTALLDIR]

23:49:17.652     addordelete: delete

23:49:17.652   Action properties:

23:49:17.652        $du.dir:

/opt/appl2/BI4/InstallData/InstallCache/platform.services.jobprocessing.programschedulingservice-4.0-core-64/14.0.5.882/

23:49:17.653     setup.core.prime-4.0-core$INSTALLDIR: /opt/appl2/BI4/

23:49:17.664 Parsing file:

/opt/appl2/BI4/InstallData/InstallCache/setup.core-4.0-core-64/14.0.5.882/actions/strings/en.uitext.xml

23:49:17.795 Number of strings parsed: 29

23:49:17.795 PerlUIProgressMonitor::setTaskName()

23:49:17.795 ProgressMonitorPerl:: - setTaskName: Removing registry keys23:49:17.795 set Value TaskName = Removing registry keys

23:49:17.795 set Value ProgressDialogUnixFooter =

23:49:17.856 ProgressMonitorPerl:: - subTask :

23:49:17.856 set Value SubTaskName =

23:49:17.856 set Value ProgressDialogUnixFooter =

23:49:17.912 Performing action in EXECUTE mode.

23:49:17.912   Action id:         RemoveFromRegistry

23:49:17.912   Source name:       WriteRegistry.pm

23:49:17.912   Source type:       perl

23:49:17.912   Source entry pt:   WriteToRegistry

23:49:17.912   Action source dir:

/opt/appl2/BI4/InstallData/InstallCache/setup.core-4.0-core-64/14.0.5.882/

23:49:17.912   Action model:      64

23:49:17.913 ExecuteAction: calling actionExecutor->ExecuteAction()

23:49:17.913 sourceDir is set to:

/opt/appl2/BI4/InstallData/InstallCache/setup.core-4.0-core-64/14.0.5.882/actions/

23:49:17.913 sourceFileName is set to: WriteRegistry.pm

23:49:17.913 action invocation dir

/opt/appl2/BI4/InstallData/InvocationData/7/uninstall/0-3-0/ does not

exists; creating ...

23:49:17.913 Redirect to temp file

/opt/appl2/BI4/InstallData/InvocationData/7/uninstall/0-3-0/perl_stderr_temp

23:49:18.089 Parse registry table file:

/opt/appl2/BI4/InstallData/InstallCache/platform.services.jobprocessing.programschedulingservice-4.0-core-64/14.0.5.882/registry.table.ini

23:49:18.103 Parse boconfig file: /opt/appl2/BI4/setup/boconfig.cfg

23:49:18.124 Number of registry nodes read: 211, keys read: 357

23:49:18.125 Queue boe_regedit: delete "SOFTWARE\SAP

BusinessObjects\Suite XI 4.0\Job Server\Program Scheduling" "BinDir"

23:49:18.125 Deleting key from boconfig "SOFTWARE\SAP

BusinessObjects\Suite XI 4.0\Job Server\Program Scheduling": BinDir

23:49:18.125 Queue boe_regedit: delete "SOFTWARE\SAP

BusinessObjects\Suite XI 4.0\Job Server\Program Scheduling" "ConfDir"

23:49:18.125 Deleting key from boconfig "SOFTWARE\SAP

BusinessObjects\Suite XI 4.0\Job Server\Program Scheduling": ConfDir

23:49:18.125 Queue boe_regedit: delete "SOFTWARE\SAP

BusinessObjects\Suite XI 4.0\Job Server\Program Scheduling" "Jre"

23:49:18.126 Deleting key from boconfig "SOFTWARE\SAP

BusinessObjects\Suite XI 4.0\Job Server\Program Scheduling": Jre

23:49:18.126 Queue boe_regedit: delete "SOFTWARE\SAP

BusinessObjects\Suite XI 4.0\Job Server\Program Scheduling"

"SharedClassesInstallDir"

23:49:18.126 Deleting key from boconfig "SOFTWARE\SAP

BusinessObjects\Suite XI 4.0\Job Server\Program Scheduling":

SharedClassesInstallDir

23:49:18.126 === BEGIN: .

/opt/appl2/BI4/sap_bobj/enterprise_xi40/linux_x64//../../setup/env.sh;/opt/appl2/BI4/sap_bobj/enterprise_xi40/linux_x64//boe_regedit

batch

/opt/appl2/BI4/InstallData/InvocationData/7/uninstall/0-3-0/platform.services.jobprocessing.programschedulingservice-4.0-core-64,14.0.5.882.boeregedit.64.sh

2>&1

23:49:18.126 Working directory:

/opt/appl2/BI4/InstallData/logs/2013.10.11.22.59.54

23:52:27.534

23:52:27.534 Return code: 0

23:52:27.534 ===   END: .

/opt/appl2/BI4/sap_bobj/enterprise_xi40/linux_x64//../../setup/env.sh;/opt/appl2/BI4/sap_bobj/enterprise_xi40/linux_x64//boe_regedit

batch

/opt/appl2/BI4/InstallData/InvocationData/7/uninstall/0-3-0/platform.services.jobprocessing.programschedulingservice-4.0-core-64,14.0.5.882.boeregedit.64.sh

2>&1

23:52:27.534 Update boconfig file: /opt/appl2/BI4/setup/boconfig.cfg - 4keys changed

23:52:27.543 Number of registry nodes written: 211, keys written: 353

23:52:27.553 *** Action returned success.

--

-- WRITE REGISTRY KEY

--

03:36:37.294 Running action: WriteToRegistry

(tp.sun.jdk-1.6-core-64,14.0.6.1036) <0, 6, 1>

03:36:37.294   Action args:

03:36:37.294       BinDir32:

[INSTALLDIR]sap_bobj/enterprise_xi40/linux_x86/

03:36:37.294       BinDir64:

[INSTALLDIR]sap_bobj/enterprise_xi40/linux_x64/

03:36:37.295          DUDir: [$du.dir]

03:36:37.295     ObjectModel: 64

03:36:37.295          Props: INSTALLDIR="[INSTALLDIR]"

03:36:37.295        RootDir: [INSTALLDIR]

03:36:37.295     addordelete: add

03:36:37.295   Action properties:

03:36:37.295        $du.dir:

/opt/appl2/BI4/InstallData/InstallCache/tp.sun.jdk-1.6-core-64/14.0.6.1036/

03:36:37.296     setup.core.prime-4.0-core$INSTALLDIR: /opt/appl2/BI4/

03:36:37.296 Parsing file:

/opt/appl2/BI4/InstallData/InstallCache/setup.core-4.0-core-64/14.0.7.1147/actions/strings/en.uitext.xml

03:36:37.298 Number of strings parsed: 49

03:36:37.298 PerlUIProgressMonitor::setTaskName()

03:36:37.298 ProgressMonitorPerl:: - setTaskName: Updating registry

03:36:37.298 set Value TaskName = Updating registry

03:36:37.298 set Value ProgressDialogUnixFooter =

03:36:37.313 ProgressMonitorPerl:: - subTask :

03:36:37.313 set Value SubTaskName =

03:36:37.314 set Value ProgressDialogUnixFooter =

03:36:37.327 Performing action in EXECUTE mode.

03:36:37.327   Action id:         WriteToRegistry

03:36:37.327   Source name:       WriteRegistry.pm

03:36:37.327   Source type:       perl

03:36:37.327   Source entry pt:   WriteToRegistry

03:36:37.327   Action source dir:

/opt/appl2/BI4/InstallData/InstallCache/setup.core-4.0-core-64/14.0.7.1147/

03:36:37.327   Action model:      64

03:36:37.328 ExecuteAction: calling actionExecutor->ExecuteAction()

03:36:37.328 sourceDir is set to:

/opt/appl2/BI4/InstallData/InstallCache/setup.core-4.0-core-64/14.0.7.1147/actions/

03:36:37.328 sourceFileName is set to: WriteRegistry.pm

03:36:37.328 action invocation dir

/opt/appl2/BI4/InstallData/InvocationData/7/install/0-6-1/ does not

exists; creating ...

03:36:37.328 Redirect to temp file

/opt/appl2/BI4/InstallData/InvocationData/7/install/0-6-1/perl_stderr_temp

03:36:37.332 Parse registry table file:

/opt/appl2/BI4/InstallData/InstallCache/tp.sun.jdk-1.6-core-64/14.0.6.1036/registry.table.ini

03:36:37.344 Parse boconfig file: /opt/appl2/BI4/setup/boconfig.cfg

03:36:37.345 Number of registry nodes read: 18, keys read: 42

03:36:37.346 Queue boe_regedit: addString "SOFTWARE\SAP

BusinessObjects\Suite XI 4.0\Installer" "JDKPath"

"/opt/appl2/BI4/sap_bobj/enterprise_xi40/linux_x64/jdk/"

03:36:37.346 Creating new registry node in boconfig: SOFTWARE\SAP

BusinessObjects\Suite XI 4.0\Installer

03:36:37.346 Queue boe_regedit: addString "SOFTWARE\SAP

BusinessObjects\Suite XI 4.0\Installer" "JDKVersion" "1.6.0"

03:36:37.346 Creating new registry node in boconfig: SOFTWARE\SAP

BusinessObjects\Suite XI 4.0\Installer

03:36:37.347 === BEGIN: .

/opt/appl2/BI4/sap_bobj/enterprise_xi40/linux_x64//../../setup/env.sh;/opt/appl2/BI4/sap_bobj/enterprise_xi40/linux_x64//boe_regedit

batch

/opt/appl2/BI4/InstallData/InvocationData/7/install/0-6-1/tp.sun.jdk-1.6-core-64,14.0.6.1036.boeregedit.64.sh

2>&1

03:36:37.347 Working directory:

/opt/appl2/BI4/InstallData/logs/2013.10.11.22.59.54

03:39:46.707

03:39:46.707 Return code: 0

03:39:46.707 ===   END: .

/opt/appl2/BI4/sap_bobj/enterprise_xi40/linux_x64//../../setup/env.sh;/opt/appl2/BI4/sap_bobj/enterprise_xi40/linux_x64//boe_regedit

batch

/opt/appl2/BI4/InstallData/InvocationData/7/install/0-6-1/tp.sun.jdk-1.6-core-64,14.0.6.1036.boeregedit.64.sh

2>&1

03:39:46.707 Update boconfig file: /opt/appl2/BI4/setup/boconfig.cfg - 2keys changed

03:39:46.709 Number of registry nodes written: 18, keys written: 44

03:39:46.711 *** Action returned success.

The installation completed successfully but the total time on test environment forced us to perform the upgrade actions during the weekend for the production environment. Additionally, this behavior was identical on both environments of the customer (test -production). Any information or help regarding would be highly appreciated.

Best regards,

Ilias Fytrakis

[former_member262506 · Accepted solution]

Hi Ilias,

   Is it possible that an unsupported CMS repository version is causing this delay?

According to PAM references the supported cms database/client version for 11g R2 is general:

11gR2  Oracle Net Client 11g R2

while on supported datasources are separated for Oracle exadata and just Oracle DB:

Oracle DB	11gR2	JDBC	SQL	Oracle JDBC 11g R2
Oracle DB	11gR2	Oracle OCI	SQL	Oracle OCI 11g R2
Oracle Exadata	11	OCI	SQL	OCI Driver Version 11.1.0.6
Oracle Exadata	11	JDBC	SQL	JDBC Driver Version 11.2.0.1.0

[Former Member · Accepted solution]

Hi Argiris,

I have been given the installation logs and those are the installation duration for various SP's of BI 4.0.

SP4.0

Installation Duration: ~1hr 15min

SP5.0

Installation Duration: ~1hr

SP5.4

Installation Duration: ~1hr

I will also ask if any changes were made to the infrastructure of the vm host, rdbms, because they didn't make any update on the operating system.

Thanks for your reply.

[dkarag]

You should open a Service Request on SAP Support.

SAP Support will investigate your issue, connect remotely via NetViewer & finally helps you resolve the issue.

[Former Member]

Hi Dimitris,

I've opened a case with SAP after we finished the installation successfully. All logs were passed to SAP support for further investigation.

[Former Member]

Did you get a chance to check the free space available for the user installation? This is another factor which can impact performance.

[Former Member]

Hi Arvind,

Yes we had check that and the available space on the disks was 100+ GB. Additionally, I've found Java Bug JDK-6483406 : new ServerSocket() sometimes takes more than 3 minutes on Suse Linux (link). The 3 minutes interval matches the pattern which I identified in the installation logs. So, any under-the-hood information regarding removing & writing of registry keys would be really useful.

Finally, the total size of the filestore is ~60GB but I don't know how this could affect the installation.

Thanks,

Ilias

[denis_konovalov]

Sounds like you found a bug that explains the behavior. I'd suggest opening support ticket with SAP under BC-JVM component, so the Java behavior on Suse can be addressed and another under BI-BIP-DEP component, so the installer can be reviewed.

[Former Member]

Hello Denis,

I've already opened a case with SAP but I wasn't sent any reply since 29/10/2013. Probably it has to do with the priority of the case (medium).

Additionally, I wasn't able to reproduce the aforementioned behavior on a test virtual machine with the same O/S & Java version and less resources. In my test environment the installation took approximately 1 1/2 hours for SP07.

Thanks for your answer,

Ilias

[denis_konovalov]

Interesting, even medium priority should have been answered faster....  what component did you log it under ?

Give me case number, let me see what's goin on with it , you can send it via private message.

[Former Member]

Dear Denis,

Another interesting observation from the startup / shutdown sequence of the services (BI / Tomcat) on the environment of our customer:

Shutdown Times

-- BI Servers

<user>@<server>:<install_directory>/sap_bobj> date

Tue Dec 3 17:30:48 EET 2013

<user>@<server>:<install_directory>/sap_bobj> ./stopservers

Stopping all...

Stopping bi4prd...

<user>@<server>:<install_directory>/sap_bobj> date

Tue Dec 3 17:34:22 EET 2013

-- Tomcat

<user>@<server>:<install_directory>/sap_bobj> date

Tue Dec 3 17:31:36 EET 2013

<user>@<server>:<install_directory>/sap_bobj> ./tomcatshutdown.sh

<user>@<server>:<install_directory>/sap_bobj> date

Tue Dec 3 17:34:54 EET 2013

Startup Times

-- BI Servers

<user>@<server>:<install_directory>/sap_bobj> date

Tue Dec 3 17:41:50 EET 2013

<user>@<server>:<install_directory>/sap_bobj> ./startservers

Starting all servers...

Starting bi4prd...

<user>@<server>:<install_directory>/sap_bobj> date

Tue Dec 3 17:45:07 EET 2013

-- Tomcat

<user>@<server>:<install_directory>/sap_bobj> date

Tue Dec 3 17:43:02 EET 2013

<user>@<server>:<install_directory>/sap_bobj> ./tomcatstartup.sh

<user>@<server>:<install_directory>/sap_bobj> date

Tue Dec 3 17:46:18 EET 2013

Please notice the ~3minutes + 10-20 seconds interval between service shutdown/start up for both service categories (BI, Tomcat). I think that this might be relevant with our case, since in a similar test vm environment the services do not suffer from such a delay.

I will open a case under BC-JVM component as you proposed me.

Thanks for the initial recommendation,

Ilias