gzip-ing smatdb files

The wal and shm files are temporary files the are cleaned up when the database is closed, which happens when you cycle or stop the engine.

Not sure what you mean by gone.  Is the data gone or you just are not seeing the smatdb files after you cycle them?

I’m just going to throw this out and see if it sticks….

Do you have smatdb encryption turned on?

Are you gunzipping to a directory other than your process directory?

If so, that may be your issue.

There is something about the site/processname involved as a key in an encrypted smatdb.

I ran into the same issue with CL 6.1.1.   What I have found is that since I am running with the SMATDB encrypted, and the engine runs as user “hci”, if I try to do anything with the smatdb files as a different user, they are corrupted and can’t be accessed again.   You can’t even move the files to another directory as a different user.

From what I have seen, it dosn’t help much to gzip the smatdb files anyway, they don’t compress much.  For long term storage I am looking at converting them to the old smat file format and then gzipping them up.

I have not finished working out this process yet.  For the time being I have created an additional partition on my box with more storage space /smathist and in each of the process directories in the SmatHistory directory (if you have smat history turned on)  I am creating a soft link (AIX os) to /smathist/ and naming it “HISTORY”.  Then any smat files older than 60 days I am moving to HISTORY.  This way when you are in the smatdb tool you can drill down to files in the SmatHistory folder and in there is another filder called HISTORY where you can see everything that is on the additional partition.

I am currently working on the script that will go through all the process directories and create the link if it dosn’t exist and move the older files to the HISTORY folder/link.