Comments for page "Data Archive Manager"

(no title)

Fri, 19 Aug 2011 10:18:05 +0000

That's odd, so the index does not exist on PSACCESSLOG, or are there duplicated rows in PSACCESSLOG causing a problem with building the index?

Do you get any rows returned checking for duplicated data using this SQL?

 select OPRID, LOGIPADDRESS, LOGINDTTM from PSACCESSLOG group by OPRID, LOGIPADDRESS, LOGINDTTM having count(*) > 1;

(no title)

Tue, 16 Aug 2011 08:52:27 +0000

Hi Praj,

I'm using the PeopleTools 8.51 and PA 9.1 (which is not relevant i guess…). I cannot reproduce your exemple due to the fact that PSACCESLOG doesn't have an unique index. So… in the step "Create the Archive Object" I cannot save the archive object, due to this error. What can I do? Is there any work around?

Thanks for the answer.

(no title)

Tue, 05 Jul 2011 20:18:40 +0000

Thanks for the feedback, it's good to hear!

I'd say running stats/analysis is always going to be helpful. I don't recall if any of the steps in data archive manager do this for you, but it wouldn't hurt to do again.

(no title)

Thu, 30 Jun 2011 03:23:52 +0000

Hi Praj,

Excellent article.

Also, I feel that the comments above (with all due respect) are exceptional cases. Usually, in a Production Environment, we would be looking at Archiving Data which has unique keys anyway.
Another thing is we can convert the history table into flat files using PeopleTools > Archive Data > Export History Files to Flat Files. This becomes handy when we dont want to store the history in the database.

Question for you:
Do we need to run stats or analyze the main table after we run the delete process?
Thanks.

Re: Not so good on tables without unique keys

Fri, 18 Dec 2009 17:54:38 +0000

Thanks. I broke it again. If you run multiple selection processes for different archive templates concurrently, it can only access one of them afterward, leaving you with a hanging archive that you cannot use for delete or restore.

Cool product, but like many other PS things, a little rough around the edges.

Re: Not so good on tables without unique keys

Thu, 17 Dec 2009 22:45:54 +0000

Thanks for your comments. I've updated the article with a warning message that points this out.

Not so good on tables without unique keys

Thu, 17 Dec 2009 21:43:24 +0000

If a table does not have a unique key, like PSACCESSLOG does not, it does not generate the delete correctly, and deletes more rows than it should when doing a delete based on the batch. It uses a partial key. Take a look at the "View Details->View SQL" or "View Detail->Count Rows".

You may want to add a note about checking the number of rows for delete if working by batch rather than by query. It may also be necessary to create your own delete query for some tables to help tools find the right rows to clean up.