Read from:
http://blogs.oracle.com/UPGRADE/2011/03/new_hidden_parameters_in_oracl.html
_DATAFILE_WRITE_ERRORS_CRASH_INSTANCE=TRUE|FALSE
_MEMORY_IMM_MODE_WITHOUT_AUTOSGA=TRUE|FALSE
Wednesday, April 27, 2011
Monday, April 25, 2011
Using Unix Scripts to Start and Stop Weblogic Managed Servers with Node Manager
In my startup script, I start the Node Manager, then start the Managed Server using WLST
---------------------------------
cd ${MW_HOME}/wlserver_10.3/server/bin
./startNodeManager.sh &
sleep 60
......
cd ${MW_HOME}/wlserver_10.3/common/bin
./wlst.sh ./startManagedWeblogic.py
......
In my stop script, I stop the Managed Server using WLST, then stop the Node Manager
---------------------------------
cd ${MW_HOME}/wlserver_10.3/common/bin
./wlst.sh ./stopManagedWeblogic.py
sleep 10
......
kill -9 `ps -ef|grep nodemanager|grep -v ps|awk '{print $2}'`
Here is the content of startManagedWeblogic.py
---------------------------------
nmConnect('<username>,'<password>','<domainname>','5556','<projectname>','<projectdirectory>','ssl')
nmStart('<managedServer>')
Here is the content of stopManagedWeblogic.py
---------------------------------
nmConnect ('<username>,'<password>','<domainname>','5556','<projectname>','<projectdirectory>','ssl')
nmKill('<managedServer>')
---------------------------------
cd ${MW_HOME}/wlserver_10.3/server/bin
./startNodeManager.sh &
sleep 60
......
cd ${MW_HOME}/wlserver_10.3/common/bin
./wlst.sh ./startManagedWeblogic.py
......
In my stop script, I stop the Managed Server using WLST, then stop the Node Manager
---------------------------------
cd ${MW_HOME}/wlserver_10.3/common/bin
./wlst.sh ./stopManagedWeblogic.py
sleep 10
......
kill -9 `ps -ef|grep nodemanager|grep -v ps|awk '{print $2}'`
Here is the content of startManagedWeblogic.py
---------------------------------
nmConnect('<username>,'<password>','<domainname>','5556','<projectname>','<projectdirectory>','ssl')
nmStart('<managedServer>')
Here is the content of stopManagedWeblogic.py
---------------------------------
nmConnect ('<username>,'<password>','<domainname>','5556','<projectname>','<projectdirectory>','ssl')
nmKill('<managedServer>')
Customize Weblogic Managed Server Start Properties in the Admin Console
After the creation of the managed servers, we often need to customize their 'Server Start' properties in the Admin Console in order to start them properly with the Admin Console. Below is a screenshot of my configuration here:
Except the 'Class Path' and 'Arguments' properties, other properties are straight-forward and easy to fill in.
For the two properties, my experience was to first start the managed server with the script startManagedWebLogic.sh, then do a 'ps -ef|grep java' to find the managed server process. You will find the 'Class Path' with -Djava.class.path=, then you can copy and paste into the 'Class Path' property in the Admin Console; You will also find some java arguments from the process that you can copy and paste into the 'Arguments' property.
You often need to adjust the arguments to increase the Java heap size, as with the defaults you are likely to get out of memory errors. Also you can add your own arguments there. For example, we added '-Ddenv=dev1' to for the applications to identify which nodes they are running in a cluster environment.
Saved the configuration. The managed servers then will be started with the customized properties, with the startManagedWebLogic.sh cript, Admin Console or Node Manager.
Except the 'Class Path' and 'Arguments' properties, other properties are straight-forward and easy to fill in.
For the two properties, my experience was to first start the managed server with the script startManagedWebLogic.sh, then do a 'ps -ef|grep java' to find the managed server process. You will find the 'Class Path' with -Djava.class.path=, then you can copy and paste into the 'Class Path' property in the Admin Console; You will also find some java arguments from the process that you can copy and paste into the 'Arguments' property.
You often need to adjust the arguments to increase the Java heap size, as with the defaults you are likely to get out of memory errors. Also you can add your own arguments there. For example, we added '-Ddenv=dev1' to for the applications to identify which nodes they are running in a cluster environment.
Saved the configuration. The managed servers then will be started with the customized properties, with the startManagedWebLogic.sh cript, Admin Console or Node Manager.
Thursday, April 7, 2011
Backup DataStage Project Assets
Using istool, I developed a script that accepts the project name as a parameter and backs up the entire project assets. The istool command is called in the script in the following way:
./istool export -domain $was_domname -u $username -p $passwd -archive $archname -datastage "-incdep -base=$DOMAINNAME/$PROJNAME */*.*"
Things I noticed:
- I use double quotation to quote the -datastage parameters instead of the single quotation (as said in the mannual), because I have to pass the domainname and projectname as shell script variables that cannot be quoted in single quotation. And the double quotation work.
- To backup the entire project assets, specify */*.*. It only takes one * and backs up all sub-folders recursively, */*/*.* or more * won't work.
- Note the istool export can only be imported as a whole, you cannot select individual object to import. To be able to select individual object to import, you need to use dsexport or dscmdexport to export, then using dsimport or dscmdimport to import. dsexport is a interactive tool while dscmdexport is a non-interactive tool that you can schedule job with Windows task manager.
- istool exists on both the client and the server, so you can schedule the export as a cron job if your server is on Linux/Unix. But dsexport and dscmdexport only exist on the client.
- dsexport is an interactive tool while dscmdexport is a non-interactive tool that you can use it to schedule job with Windows task manager.
./istool export -domain $was_domname -u $username -p $passwd -archive $archname -datastage "-incdep -base=$DOMAINNAME/$PROJNAME */*.*"
Things I noticed:
- I use double quotation to quote the -datastage parameters instead of the single quotation (as said in the mannual), because I have to pass the domainname and projectname as shell script variables that cannot be quoted in single quotation. And the double quotation work.
- To backup the entire project assets, specify */*.*. It only takes one * and backs up all sub-folders recursively, */*/*.* or more * won't work.
- Note the istool export can only be imported as a whole, you cannot select individual object to import. To be able to select individual object to import, you need to use dsexport or dscmdexport to export, then using dsimport or dscmdimport to import. dsexport is a interactive tool while dscmdexport is a non-interactive tool that you can schedule job with Windows task manager.
- istool exists on both the client and the server, so you can schedule the export as a cron job if your server is on Linux/Unix. But dsexport and dscmdexport only exist on the client.
- dsexport is an interactive tool while dscmdexport is a non-interactive tool that you can use it to schedule job with Windows task manager.
Wednesday, April 6, 2011
DataStage 8.1 Logging Issues and How to Purge the Logs
In DataStage 8.1 logging is changed to the metadata repository database by default, which has caused some performance issues including the logs being delayed in the director, or even missed. In 8.5 IBM reverts the change and the logs are logged back to the local project log files. See the link:
https://www-304.ibm.com/support/docview.wss?dc=D600&rs=14&uid=swg21370048&context=SSZJPZ&cs=UTF-8&lang=en&loc=en_US
In addition to the performance issues, I had another issue that my metadata database was filled up quickly because the logs in the xmeta would never been purged by the system. Before I realized it, the xmeta tablespace was already 30GB and the majority of the space was consumed by a table called LOGGING_LOGGINGEVENT1466CB5F, which had over 6 million records. I needed to purge the logs and release the space.
In my case, I looked into two ways to purge the logs:
- Invoke: $ISHOME/ASBServer/bin/PropertyAdmin.sh -unset -key minimalISFInitialization
- Start: $ISHOME/ASBServer/bin/MetadataServer.sh start
After that, I was able to schedule a purge job with LoggingAdmin.sh and removed the log entries from the table. However it was not done yet. I needed to free LOB space, see my another note:
http://ccdba-net.blogspot.com/2010/09/undo-data-for-lob-segment-is-kept.html
The SQL commands I used:
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(CIT1_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(CIT2_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(CIT3_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(CIT4_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(CIT5_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(CIT6_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(CONTEXT_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(MESSAGE_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(THROWABLEINFO_XMETA) (shrink space cascade);
ALTER TABLE xmeta.LOGGING_LOGGINGEVENT1466CB5F ENABLE ROW MOVEMENT;
ALTER TABLE xmeta.LOGGING_LOGGINGEVENT1466CB5F SHRINK SPACE CASCADE;
ALTER TABLE xmeta.LOGGING_LOGGINGEVENT1466CB5F DISABLE ROW MOVEMENT;
But still, I was not done yet, the database data file wouldn't shrink due to high water mark usage. My last thing was to shutdown the server, export the xmeta schema out, drop and recreate the tablespace then import the xmeta schema back, then bring up the server.
https://www-304.ibm.com/support/docview.wss?dc=D600&rs=14&uid=swg21370048&context=SSZJPZ&cs=UTF-8&lang=en&loc=en_US
In addition to the performance issues, I had another issue that my metadata database was filled up quickly because the logs in the xmeta would never been purged by the system. Before I realized it, the xmeta tablespace was already 30GB and the majority of the space was consumed by a table called LOGGING_LOGGINGEVENT1466CB5F, which had over 6 million records. I needed to purge the logs and release the space.
In my case, I looked into two ways to purge the logs:
- Using the Information Server web console. I created a log view 'ALL' with all the categories - but really later when querying the table (group by the column CATEGORYNAME_XMETA) I found the majority of the record is IIS-DSTAGE-RUN category. Then I tried to purge the log view, but my web console session timed out every once a while with just some number of records being purged. I could repeat the way many times until all the records were purged but I decided to go with the second way of using LoggingAdmin.sh, as mentioned in the above IBM link.
- Using LoggingAdmin.sh. My initial try failed with Java class not being found errors. After worked with IBM support, it was found out the Websphere was in what is known as the minimal initialization state, meaning only a few of the services were active which didn't include the scheduling service. I was asked to put the WAS back to the normal state with commands:
- Invoke: $ISHOME/ASBServer/bin/PropertyAdmin.sh -unset -key minimalISFInitialization
- Start: $ISHOME/ASBServer/bin/MetadataServer.sh start
After that, I was able to schedule a purge job with LoggingAdmin.sh and removed the log entries from the table. However it was not done yet. I needed to free LOB space, see my another note:
http://ccdba-net.blogspot.com/2010/09/undo-data-for-lob-segment-is-kept.html
The SQL commands I used:
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(CIT1_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(CIT2_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(CIT3_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(CIT4_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(CIT5_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(CIT6_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(CONTEXT_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(MESSAGE_XMETA) (shrink space cascade);
alter table xmeta.LOGGING_LOGGINGEVENT1466CB5F modify lob(THROWABLEINFO_XMETA) (shrink space cascade);
ALTER TABLE xmeta.LOGGING_LOGGINGEVENT1466CB5F ENABLE ROW MOVEMENT;
ALTER TABLE xmeta.LOGGING_LOGGINGEVENT1466CB5F SHRINK SPACE CASCADE;
ALTER TABLE xmeta.LOGGING_LOGGINGEVENT1466CB5F DISABLE ROW MOVEMENT;
But still, I was not done yet, the database data file wouldn't shrink due to high water mark usage. My last thing was to shutdown the server, export the xmeta schema out, drop and recreate the tablespace then import the xmeta schema back, then bring up the server.
Subscribe to:
Posts (Atom)