Blog

Hi,

Its been a while since I posted, today a wrote a quick script that will take a backup of Informatica .rep file and store it in a specified location. The script works in any Unix/Linux based system if you create a cron job for how often you want to take the backup the script will do the rest.

The script needs some parameters to work effectively if you add you settings then the rest of the script should work without an issue.

#!/bin/ksh
 #
 # +############################################################+
 # # #
 # # Author: Andrew Pazikas #
 # # Date : 05/06/13 #
 # # Desc : Takes a backup of Informatica Metadata #
 # # Change Log: #
 # # 05/06/13 Andrew Pazikas Initial version #
 # # #
 # # #
 # # #
 # +############################################################+
 #set -x

. $HOME/.profile

export BACKUP_DIR='where you want to store your backups'
 export INFA_REPO_NAME='Informatica Repository Name'
 export INFA_DOMAIN_NAME='Informatica Domain Name'
 export INFA_USER='Informatica User Namer'
 export INFA_PASS='Informatica Password '
 export DAYS_TO_KEEP_BACKUP=30
 export LOG_HOME='location on where you want to keep the backup log'
 #########Take backup of Infa Repo##############
 cd $INFA_HOME

pmrep connect -r $INFA_REPO_NAME -d $INFA_DOMAIN_NAME -n $INFA_USER -x $INFA_PASS > $LOG_HOME/pmrep_conn.log

pmrep backup -o $BACKUP_DIR/infa_repo_backup_$(date +%y%m%d).rep
 #########Remove files older than DAYS_TO_KEEP_BACKUP #########
 cd $BACKUP_DIR
 find . -mtime +$DAYS_TO_KEEP_BACKUP -exec rm {} \;

cd $LOG_HOME
 find . -mtime +$DAYS_TO_KEEP_BACKUP -exec rm {} \;
 exit
 EOF

Until Next time

Cheers

For the second part of my OBIEE Tuning guide we will look at the instanceconfig.xml and changes that can be made here. As stated in my previous post I dont believe in cache when performance tuning as it can lead to false results, in that respect make sure cache is turned off in OBIEE Enterprise Manager, the below settings can be set by editing the instanceconfig.xml file.

<Table>
 <MaxCells – 200000>
 <MaxVisibleColumns - 1000>
 <MaxVisiblePages – 1000>
 <MaxVisibleRows – 100000>
 <MaxVisibleSections – 1000>
 <Table>
 <DefaultRowsDisplayed – 25>
 <DefaultRowsDisplayedInDownload – 2500>

<Pivot>
 <MaxCells – 200000>
 <MaxVisibleColumns - 1000>
 <MaxVisiblePages – 1000>
 <MaxVisibleRows – 100000>
 <MaxVisibleSections – 1000>
 <Pivot>
 <DefaultRowsDisplayed – 25>
 <DefaultRowsDisplayedInDownload – 2500>

<ThreadPoolDefaults>
 <ChartThreadPool>
 <MaxQueue>2048</MaxQueue>
 <MaxThreads>**</MaxThreads> (Max Threads no. cores x 8)
 </ChartThreadPool>
 </ThreadPoolDefaults>

<Cursors>
 <NewCursorWaitSeconds>10</NewCursorWaitSeconds>
 </Cursors>

<Catalog>
 <LockStaleSecsSoft>14400</LockStaleSecsSoft>
 <LockStaleSecsHard>14400</LockStaleSecsHard>
 <HashUserHomeDirectories>3</HashUserHomeDirectories>
 <UpgradeAndExit>false</UpgradeAndExit>
 </Catalog>

<BIEEHomeLists>
 <Enabled>false</Enabled>

With the above changed made I restarted all services including the database to ensure an accurate report running time was recorded.

Results:
Time after changing NQServer.ini Time with instanceconfig.xml changes
1. 1m54s 1m44s
2. 2m46s 2m56s
3. 5m13s 5m15s
4. 2m34s 2m42s

Looks like the reports performed slightly worse than before. Even with reports running worse I left the settings in as with my original post only a 10s or more differnece either way will count as an improvment.

Until next time I will show the changed made to the Data Warehouse itself.