Shell Script to monitor Virtual Bytes for Sawserver & NQSServer

Hi Friends,

I was troubleshooting gradual increase in physical memory consumption for Sawserver & NQSServer in our environment.

One requirement was to observe the gradual increase my logging the virtual bytes using a shell script every 5 minutes.

The command was simple: ps -ef -o vsz,pcpu,args | grep sawserver64

To automate it, i wrote a small shell script which will write the output of above command every 5minutes, until I kill the script execution:


If you go over the logic, i have wrote a never ending while loop which writes timestamp, virtual byte information for sawserver & nqsserver and included a sleep command to pause the execution for 5mins.

Customizable Sections:
1) You can add more processes to be monitored for Virtual Bytes.
2) Sleep time can be increase on decreased. It accepts input in seconds, i.e. 300=5mins

How to Invoke:
1)Make sure that the script has executable rights or do chmod 777 VirtualByteTrace.sh
2)Invoke the script in background mode: bash-$./VirtualByteTrace.sh &

Output:

Tested successfully on Sun Solaris 10 platform.
Hope this helps you for any other process as well :-)

Keywords:
OBIEE, Sawserver, Sawserver64, NQSServer, Shell Script, Unix, Solaris, OBIEE 10.1.3.4.1, etc

oracle.apps.xdo.security.ValidateException

Hi Friends,

As promised in my first brush with BI Publisher post, the next error i faced was oracle.apps.xdo.security.ValidateException

Well, this was because the BI Publisher's security model was set to "BI Server" as BI Publisher was installed as part of OBIEE 10.1.3.4.1

Now, it is obvious that the RPD "Administrator" user password is changed from the default password "Administrator" & also the RPD must be missing the BI Publisher Security Groups with "Administrator" user added to XMLP_ADMIN group.

So before we proceed & understand the different Security Models & ways to counter the BI Publisher Authentication woes, it is must to setup a Super User in BI Publisher.

Super User is a fundamental used in BI Publisher which allows to have a one super admin regardless of whatever security model you configure. Due to this feature BI Publisher allows you to login & configure the BI Publisher system through one common super admin user.

In order to achieve this, you will first need to change the xmlp-server-config.xml file available under /xmlp/XMLP/Admin/Configuration/ folder:
Change the following line:
<property name="SECURITY_MODEL" value="BI Server"/>
TO
<property name="SECURITY_MODEL" value="XDO"/>

Setting the Security Model to XDO means, you are configuring the BI Publisher to use its builtin BI Publisher security model.

After you make this change, stop & restart your J2EE Application server.
Now try to access your BI Publisher using URL: http://host:port/xmlpserver/ & login using following details
User: Administrator
Password: Administrator

You should be inside BI Publisher now :-)!
Click the Admin Tab & under the "Security Center" section, click: Security Configuration

Inside "Local Superuser" section:
a) Enable the checkbox for "Enable Local Superuser
b) Choose a suitable "Superuser name"
c) Choose a suitable "Password"
d) Click the "Apply" button on the top right-hand corner.

e) Restart your J2EE App Server & try logging in using your Super user
If you can successfully login into the BI Publisher system, it makes way for you to start fidling with the other available Security Models for BI Publisher.

I will cover the other Security Models in upcoming posts.
Stay tuned!

Keywords:
BI Publisher, Tomcat, Apache, ResourceNotFoundException, OBIEE, 10.1.3.4.1, XML Publisher, Security Model, XDO, BI Server, SIEBEL etc

oracle.apps.xdo.servlet.resources.ResourceNotFoundException

Hi Friends,

As promised in my first brush with BI Publisher post, the next error i faced was
oracle.apps.xdo.servlet.resources.ResourceNotFoundException "${oracle.home}/xdo/repository"

Well, i simply dont understand why does such nagging errors always come up.

Why does it happen?
The BI Publisher always need its Repository location to be defined in xmlp-server-config_orig.xml
Now had the BI Publisher being deployed on OC4J or OAS (Oracle Application Server), then the default path would have worked as a charm (${oracle.home}/xdo/repository)
But since we are deploying our BI Publisher in custom J2EE server, we will need to configure this path before we can actually use it.

Solution?
Its simple to rectify this. If you are using BI Publisher as part of integrated OBIEE Setup, you need to find the repository path.
Generally, the repository has folder structure as:
%OBIEE_INSTALL_ROOT%
-------xmlp
             -----------XMLP
                                  --------Admin
                                  --------DemoFiles
                                  --------Reports
                                  --------Tools

So your BI Publisher Repository path is: %OBIEE_INSTALL_ROOT%/xmlp/XMLP

Now you need to make these changes in the xmlp-server-config.xml file. This file is generally available in your WEB-INF folder where you have deployed the BI Publisher WAR in the J2EE Server.
E.g. for Tomcat: /tomcat-root/webapps/xmlpserver/WEB-INF/

Edit this file & change
<b><file path="${oracle.home}/xdo/repository"></file></b>
to
<b><file path="$OBIEE_INSTALL_ROOT/xmlp/XMLP"></file></b>

Now restart Apache Tomcat Server & you should be all set for a successful login into BI Publisher.


Keywords:
BI Publisher, Tomcat, Apache, ResourceNotFoundException, OBIEE, 10.1.3.4.1, XML Publisher etc

BI Publisher: com/phaos/crypto/CipherException

Hi Friends,

My first brush with BI Publisher... As always being the case, no Enterprise standard software easily setups as said in its documentation! Thats why the need to expert Consultants to deploy & maintain the same ;-)

Following was the brief error after i tried logging in from my BI Publisher login screen:

The server encountered an internal error () that prevented it from fulfilling this request.

exception

org.apache.jasper.JasperException: com/phaos/crypto/CipherException
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:476)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:371)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:315)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
oracle.apps.xdo.servlet.security.SecurityFilter.doFilter(SecurityFilter.java:100)

root cause

javax.servlet.ServletException: com/phaos/crypto/CipherException
org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:846)
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:779)
org.apache.jsp.login_jsp._jspService(login_jsp.java:499)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:315)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
oracle.apps.xdo.servlet.security.SecurityFilter.doFilter(SecurityFilter.java:100)

root cause

java.lang.NoClassDefFoundError: com/phaos/crypto/CipherException
oracle.apps.xdo.servlet.security.SecurityHandler.getHandler(SecurityHandler.java:66)
org.apache.jsp.login_jsp._jspService(login_jsp.java:190)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:315)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
oracle.apps.xdo.servlet.security.SecurityFilter.doFilter(SecurityFilter.java:100)

note The full stack trace of the root cause is available in the Apache Tomcat/5.5.27 logs.

Ahh....i was like what the heck!

Before i proceed again, i would like to quickly give you my BI Publisher Setup Info:
J2EE Server: Apache Tomcat 5.5.27
BI Publisher: 10.1.3.4.1
Standalone/Integrated: This was installed as part of OBIEE 10.1.3.4.1 Setup & not deployed as standalone.

Now, above error clearly points to some issue with the Authentication stuff we just passed in the login screen of BI Publisher. It is actually missing few important jars & libraries which are causing the issue.

Why did this happen?
Well, as you all know, OBIEE Installation in Basic form comes with OC4J while Advanced format requires Oracle Application Server. If you dont want either of this, you need to setup your own J2EE Server & deploy these applications from the given WAR files.

Now, the packaging of WAR files in case of BI Publisher has been different for OC4J & any generic J2EE server. You are bound to deploy the normal OC4J WAR file on Tomcat & then face this error.
The OC4J specific WAR files has few libraries missing as these are already available with base OC4J setup.

Solution?
Now, if you want to recover from this problem, you will first need to undeploy the earlier WAR file deployed on Tomcat.
Once you undeploy, restart your Tomcat and then deploy the WAR (xmlpserver.war) from "generic" folder.
Exact Location for the "generic" folder:
%OBIEE_SETUP_ROOT%/Platform/Solaris/Server_Ancillary/Oracle_Business_Intelligence_Publisher/generic
Platform stands for Solaris/Linux/Windows etc
Deploy the xmlpserver.war from this generic folder on your Tomcat.

Restart Tomcat & they open your BI Publisher:
http://host:port/xmlpserver/

Try logging in using your RPD Administrator user & password since BI Publisher coming with OBIEE uses OBIEE Security Model & not that of standalone BI Publisher.

If you face any of below errors post attempting to login in BI Publisher then stay tuned!! I will be documenting the solutions soon :-)

oracle.apps.xdo.servlet.resources.ResourceNotFoundException   

OR

oracle.apps.xdo.security.ValidateException

Till then happy debugging...

Keywords:

BI Publisher, OBIEE, xmlpserver.war, RPD, CipherException, 10.1.3.4.1, XML Publisher, Tomcat etc

Exception in thread "main" java.lang.NoClassDefFoundError: oracle/bi/analytics/management/StandardConsoleAgent

Hi Friends,

This is my newest experiment going on with OBIEE Management Pack in Oracle Enterprise Manager (OEM) Tool (Oracle Management Server (OMS)) & OBIEE Application.

OBIEE Management Pack needs to read the performance values exposed over JMX. In order to start this utility, we need to configure the runagent.sh or runagent.cmd under /$OBIEE_ROOT/systemsmanagement/

Following is the sample runagent.sh file setup for a OBIEE Setup on Unix Platform:

#!/bin/sh
# this is a template of runagent.sh to be used on Unix.
# The installer will fill in JAVA_HOME, SAROOTDIR, and SATEMPDIR

export JAVA_HOME="/usr/java/jdk1.5.0_19"
export SAROOTDIR=/$OBIEE_ROOT/
export SADATADIR=/$OBIEE_DATA/
export SATEMPDIR=/$OBIEE_DATA/tmp
export UNIXPERFDIR=${SATEMPDIR}

java_cmd="${JAVA_HOME}/bin/java -Djava.library.path=${SAROOTDIR}/server/Bin -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9980 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -classpath analytics-jmx.jar:lib/xmlparserv2.jar oracle.bi.analytics.management.StandardConsoleAgent"

${java_cmd}

Now if you carefully observe, if you invoke the script from your home directory, the classpath will fail to resolve & give error like:
Exception in thread "main" java.lang.NoClassDefFoundError: oracle/bi/analytics/management/StandardConsoleAgent

Above issue is purely due to the way classpath parameter is given in java_cmd: -classpath analytics-jmx.jar:lib/xmlparserv2.jar oracle.bi.analytics.management.StandardConsoleAgent

The analytics-jmx.jar & xmlparsev2.jar are not resolved as absolute path locations are not given here. So you need to manually change your directory till /$OBIEE_ROOT/systemsmanagement/ & then invoke runagent.sh file to start the JMX Performance counters successfully.

The JMX Performance Counters needs to be exposed constantly so that OBIEE Management Pack reads correct values. To achieve this, you need to start the runagent.sh file in background mode. e.g.-bash-3.00$ runagent.sh &  or-bash-3.00$ nohup runagent.sh & so even after you logoff your session, the utility keeps running & gathers correct values.

Enjoy!

Keywords:
OBIEE, Siebel Analytics, Business Intelligence, Oracle Enterprise Manager Grid Control, OMS, Oracle Management Server, OEM, Grid Control, JMX, JAVA, OBIEE Performance, etc