SAP IQ PITR restore fails due to truncated catalog store .log files

[former_member194571]

IQ Version (@@version): SAP IQ/16.0.110.2722/10940/P/sp11.19/Enterprise Linux64 - x86_64 - 2.6.18-194.el5/64bit/2018-03-12 02:46:27

OS Version (/proc/version): Linux version 2.6.32-754.el6.x86_64 (mockbuild@x86-033.build.eng.bos.redhat.com) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC) ) #1 SMP Thu May 24 18:18:25 EDT 2018

OS Version (/etc/redhat-release): Red Hat Enterprise Linux Server release 6.7 (Santiago)

Dear all,

I’ve updated IQ from PL 06 to the above version in order to utilize PITR. As part of the update procedure, I have renamed the catalog store xact log in order to restart it. I’ve activated PITR for automatic PITR backups (SET OPTION PUBLIC.IQ_LOG_BACKUP_INTERVAL= '29')

Now, in an attempt to perform a PITR restore, I learned that the live catalog store xact log file is regularly shortened, similar to the behavior of the –m database command line option. I’ve verified that –m is not part of the command line (property('CommandLine') = -n q00qrs -cl 1024m -ch 4096m -gc 20 -gd DBA -iqlm 35000 -iqtc 35000 -iqmc 35000 -iqnumbercpus 8 -iqpartition 4 -x tcpip{port=33000} -gss 8196 -iqtss 2048 -gn 768 -gm 512 -gp 4096 -ti 4400 -p 64000 -dt /sapiq/data/QRS/temp -o /sapiq/shared/QRS/log/QRS.srvlog -on 500m -zn 5 -zo /sapiq/shared/QRS/log/QRS.rlog -zs 500m -zr sql -iqmsgsz 100 -iqmsgnum 5 /sapiq/shared/QRS/catalog/QRS.db -s none -gl all -hn 5

I’ve observed the .log start offset move:

[10:25] dbtran -c dsn=QRS -y -n /dev/null | grep offset
Missing transaction log(s) after file "/sapiq/log/QRS/180621AA.log" (ends at offset 0020869974) and the on-line transaction log starts at offset 035105048.
Transaction log "/sapiq/log/QRS/QRS.log" starts at offset 0035105048

[10:49] dbtran -c dsn=QRS -y -n /dev/null | grep offset

Missing transaction log(s) after file "/sapiq/log/QRS/180621AA.log" (ends at offset 0020869974) and the on-line transaction log starts at offset 0035110646.
Transaction log "/sapiq/log/QRS/QRS.log" starts at offset 0035110646

Between 10:25 and 10:49 (10:36), an automatic PITR log backup was performed: sysiqbackhistory.cmd = “backup database point in time recovery logs only to '/sapiq/backup/QRS/PITR/QRS_PITR_20180810_103600003'”

Does anybody have an idea what I can do to stop the QRS.log from being truncated, so I can successfully restore to a Point in Time?

TIA & best regards

Volker
DB-TecKnowledgy

[harpreet_chaudhary]

Are you doing an inplace restore or trying to do the restore to a different location ? We have a few KBA's that walks one through with steps on performing a PITR restore. Our documentation is also being updated with those examples.

Regards

Harpreet

[former_member194571]

Hi Harpreet,

I'm restoring to a different machine but to identical paths (which I have achieved by using directory level links to the target FSs). I do not use a RENAME clause in the RESTORE statements which work for the FULL and INCREMENTAL archives.

But the very basic issue is the truncation of the .log file which I observe on the live instance and in my understanding is not correct. And this happens without any awareness for possible RESTORE issues on the side of the live system.

Thanks,

Volker

[harpreet_chaudhary · Accepted solution]

Hi Volker,

I noticed you have created an incident for this. I will follow-up with you via the incident

Regards

Harpreet