Maintenance of IBM Cognos 10 BI Servers

 

During the lifetime of your IBM Cognos 10 environment you will notice a slow erosion of disk space on the drive which has the application files installed on it.

This is due to a number of files that are created during normal and exceptional operation for monitoring and troubleshooting purposes. Unless you have a third party application monitoring disk space then this can cause a major issue if you installed the software on a small capacity hard drive and you receive a call from your user community that reports are not running.

This blog article works through the areas where you can maintain your environment.

1 Memory Core Dump Files

These are the single largest cause of disk space issues. Any report that fails and causes the Batch Report / Report service to fail will generate a series of dump files which can be exceptionally large often reaching 2GB per file. The worst I have seen was 57GB of disk space on an unmanaged Cognos 8 BI Dispatcher!!

These files are stored in the ‘bin’ directory of the installation location. If you install the 64bit BI Server on a C: drive then this would be c:\Program Files\IBM\Cognos\C10_64\bin64 and c:\Program Files\IBM\Cognos\C10_64\bin64 on a 32bit server. They are really easy to spot due to their size and name.

Steps to resolve:

I. Open Windows Explorer

II. Navigate to the ‘bin’ directory

III. Sort the files by size in descending order.

IV. Delete any files that begin ‘core’ to get maximum disk space returned.

V. Delete any files that begin ‘javacore’ or ‘snap’ for completeness.

The screenshot below shows an example of the

clip_image002

Figure 1 – Illustration of execution clutter

If you prefer you can disable the creation of these files by amending a configuration file as below:

I. On the server where IBM Cognos BI is installed, open the cclWinSEHConfig.xml file from the c10_location\configuration directory.

II. In the configuration element, change the value of the environment variable setting to 0 (zero) so that it reads <env_var name="CCL_HWE_ABORT" value="0"/>

III. Save the file.

IV. Repeat the above steps for any other server(s) that could potentially run reports.

NOTE: In the event of you requiring expert diagnosis from your support partner or IBM you may need to reverse the above change to supply the dump information. This helps the support teams to accurately work out what was happening when the crash occurred.

2 Temporary Files

During report execution a number of files are written to different places and whilst the majority of the time then are deleted on occasion this doesn’t happen.

If you open Cognos Configuration and look at the Environment section below the directories of different types of file are specified.

clip_image004

Figure 2 – Temp directories

Whilst you are not expecting to reclaim massive amounts of disk space an amount of pruning can occur in here.

Deployment Location

This folder is set by default to your C10 installation location and the ‘deployment’ folder. Often this is changed to a shared location where as environment has more than once Content Manager server and will only appear on those servers where the Content Manager components are installed.

The deployment location contains files generated by Content Import and Export operations. Folder Exports and Full Content Store Exports can be found in here and the full content exports with report output included can generate large files.

RECOMMENDATION: Periodically it is good practice to review the files in this directory and delete those not required and archive those off the server that you wish to keep.

Data Location

The data location can contain a large amount of files but a small amount of disk space occupation. Below we highlight two directories ‘cqe’ and ‘xqe’.

clip_image006

Figure 3 – Data directories

CQE is the folder than contains all the Compatible Query Engine Runtime objects such as expanded packages from Cognos Connection. When you open a package for the first time it expands into the cqe\rtmodels directory and subsequent opening of the package through tools like Report Studio will use the expanded version for performance.

XQE is the location where any Dynamic Query Mode data files are kept, this only applies if you are using DQM and usually this directory is empty.

RECOMMENDATION: You can clear the contents of the cqe\RTModels directory but it is strongly recommended that the IBM Cognos windows service is stopped prior to removing any files in the ‘data’ area.

Temporary Files Location

When reports execute, DQM caches are refreshed and Content Manager Activities require files to complete actions then these are written into the Temporary files location.

There are a number of subdirectories underneath the temp folder as per the diagram below.

clip_image008

Figure 4 – Temp location sub-directories

Most of the above folders are empty but the structure should remain in place.

RECOMMENDATION: Review the temp directory folder structure and delete any *.tmp files that reside in any folder especially if they are over 24 hours old. It is reasonable to assume that these have been left by old dead processes.

3 Log Files

Log files are created by IBM Cognos 10 for a variety of processes but the main log file is called cogserver.log and by default lives in the c10 install location\logs directory.

The location for the log files is specified in Cognos Configuration:

clip_image010

Figure 5 – Logging Settings

When the cogserver.log file exceeds the Maximum size defined above it is renamed to cogserver.log.1 and any previous one deleted. If you increase the number of maximum full log files then it is possible to retain more history.

Types of Files

The logs directory contains a number of type of log file.

clip_image012

Figure 6 – Log Files Directory

Admin Log Files

These files are created when the IBM Cognos is started and will record any issues that have been recorded in the administrative functions of IBM Cognos 10.

FILENAME FORMAT: admin.yyyy-mm-dd.log

RECOMMENDATION: Delete all except the one with the most recent date.

 

Catalina Log Files

These log files contain any faults relating to the apache tomcat application server.

FILENAME FORMAT: catalina.yyyy-mm-dd.log

RECOMMENDATION: Delete all except the one with the most recent date.

 

Configuration Test Result Files

These files simply store results of the tests of components whilst the IBM Cognos windows services is started.

FILENAME FORMAT: cbs_cnfgtest_nnnn

RECOMMENDATION: Delete all.

 

CBS Log Files

These files tell us starting status’ etc and are replaced on every startup of the IBM Cognos service.

FILENAME FORMAT: cbs_*.log

RECOMMENDATION: Delete only when the IBM Cognos Service is stopped, the files are locked otherwise.

 

cmMetrics Log Files

These files store Content Manager Statistics and are not used in normal operation. They are not readable to the untrained eye.

FILENAME FORMAT: cmMetrics_yyyy-dmm-dd.log and qs_cmmetrics_yy-mm-dd.log

RECOMMENDATION: Delete only when the IBM Cognos Service is stopped, the files are locked otherwise.

Cogserver Log Files

These are the most important files for diagnosing issue. The utility called logviewv2.exe is used to view them and analyse issues. IBM Support often require it to help them diagnose issues.

FILENAME FORMAT: cogserver.log and cogserver.log.n

RECOMMENDATION: Delete only when the IBM Cognos Service is stopped, the cogserver.log file is locked otherwise. Often if you have an issue, stopping the service, deleting or archiving the log files and restarting the service to replicate the issue and generate a small log file is desirable.

Cogserver Sub Log Files

The cogserver series of log files also creates one log file per process. These only contain a small amount of information and are not of use.

FILENAME FORMAT: cogserver_default_nnnn.log

RECOMMENDATION: Delete all.

Host Manager Log Files

These files are created when the IBM Cognos is started and will record any issues that have been recorded in the management functions of IBM Cognos 10.

FILENAME FORMAT: host-manager.yyyy-mm-dd.log

RECOMMENDATION: Delete all except the one with the most recent date.


IPFInternal Log Files

These files contain any issues around the Java elements of IBM Cognos 10.

FILENAME FORMAT: ipfinternal*.log

RECOMMENDATION: Files are locked when the IBM Service is running so cannot be deleted.

Localhost Log Files

These log files contain messages relating to IIS Web Server traffic. They are useful to diagnose issues with communication but produce a lot of information to sift through.

FILENAME FORMAT: localhost.yyyy-mm-dd.log

RECOMMENDATION: Delete all except the one with the most recent date.

Manager Log Files

These files are created when the IBM Cognos is started and will record any issues that have been recorded in the management functions of IBM Cognos 10.

FILENAME FORMAT: manager.yyyy-mm-dd.log

RECOMMENDATION: Delete all except the one with the most recent date.

Pogo Log Files

These files log any startup or operational error messages and can prove useful with cogserver.log in issue resolution.

FILENAME FORMAT: pogo.yyyy-mm-dd.log and qs_pogo.yyy-mm-dd.log

RECOMMENDATION: Delete all except the one with the most recent date.

Pogo Metrics Files

Usually unreadable, these files are not really of use.

FILENAME FORMAT: pogometrics.yyyy-mm-dd.log and qs_pogometrics.yyyy-mm-dd.log

RECOMMENDATION: Delete all except the one with the most recent date.

Once cleaned an example of the logs directory looks like this:

clip_image014

Figure 7 – Clean Log directory without stopping services


XQE Folder

The XQE folder within the logs folder holds workload information relating to the Dynamic Query Mode Operation. This is very useful for improving DQM query performance and a good history in here will give the Cognos Administrator valuable data to use with Dynamic Query Analyser to suggest improvements for performance.

clip_image016

Figure 8 – XQE Folder Contents

The xqelog xml files contain details of where the workload files are. By default they are held in the usage folder and there is a one to one correlation between xml file and usage file. These are the files that are valuable to DQM Analyser.

RECOMMENDATION: Retain as much history as practical, perhaps up to six months’ worth of XML and usage data. Anything in the requestDumps directory can be deleted.

Advertisements

10 thoughts on “Maintenance of IBM Cognos 10 BI Servers

  1. Andrew,

    Thank you very much for sharing the information in detail. Excellent work!! Very helpful. I have never come across this kind of detailed explanation anywhere.

  2. Hi Andy,

    Wanted to know whether we can setup Cognos 10.2.2 with SQL Server using files.

    If yes Kindly let me know how can we find the files on which each and every configuration details is mentioned.

    I know the cogstartup.xml has the details that is mentioned in the cognos configuration but if I want to setup Cognos 10.2.2 with tomcat and SQL Server using the files and not from the cognos configuration.

    Kindly provide your suggestions on this.

    Regards,
    Vikas

    1. Hi Vikas,

      Yes indeed, SQL Server is my preferred option.

      Basically, all you need to do is:

      1… Create a blank database in SQL Server for your Content Store. I usually use the database name C1022_META for the Content Store.
      2… Optionally, create an Audit Database for your Audit Store. I usually use the database name C1022_AUDIT.
      3… Ensure that you have downloaded and installed the SQL Server Native Client for your SQL Server Version on each of your Cognos Content Manager Servers and Dispatchers.
      4… In Cognos Configuration, you need to ensure that you create a Connection to the Content Store, this is called Content Store by default and is setup for DB2 by default. You can delete this connection and create a new one pointing to SQL Server. It will ask you to provide a SQL Server name, Database Name, Username and password. For ease make sure your DBA sets up a SQL Login with db_owner rights to all Cognos Content and Audit databases.
      5… Once you have added this you can save the configuration and test it before starting the service in Cognos Configuration. Once that is starting it creates the database tables, indexes and stored proecedures automatically in the database so you don’t need to do anything.

      One recommendation though, don’t install SQL Server and Cognos on the same server unless it is a demo environment and you know how to manage memory successfully as they will strangle each other.

      Regards

      Andy

      1. Andy,

        I have a need of deleting the reports from Production which have not been executed for Past 6 Months. I pull the report and I do not know how to delete them as a bulk. The reports consists of combination of Public Folders and My Folders. Is there a way to write SQL against the Content store and use delete command from SQL to delete these reports from Content Store?

        Thank you,

        Ven

      2. Hi Ven,

        I would not recommend hacking around in the Content Store as you will end up with IBM Support not supporting you.
        The way I would get around this is to get a list of reports from your estate. I think Motio PI Pro can help you there.
        Once you have that use the standard audit reports to get what has actually executed and compare the two to get the gap.

        Regards
        Andy

  3. Hi Andy,

    In our production Content manager is connecting standby mode frequently. So, we would like know is there any script or any other ways to create automated alerts for content manager uri status Active or Standby Mode.

    Thank you in Advance.

    Regards
    Krishna M

    1. Hi,

      If you use the URL for your Content Managers http://myservername.mydomain.com:9300/p2pd/servlet and put them all into an iframe then you could in theory have them all in one screen. Your CM should not be going into standby often and it would only be through a problem that it is doing so. I would look at the cogserver.log files on the server. We have a dedicated CM in our production environment and also a standby on one of our report dispatchers.

      Are your servers periodically restarted, if so then check the order as the first one with a CM component on it is the active one by default.

      The answer to your fault if it is not in the startup order will be in the cogserver.log files. There are also some additional settings you can add to the ipftrace files which will give you more messages but slow down performance so use them on production as a last resort.

      Hope that helps, sorry for the delay.

      Regards

      Andy

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s