Re: Purge Summary Table
Ended up going to level2 support and we were able to edit the records back to 2002. Interesting process. I've been out for a couple of days but I see that the next problem is that TDS has stored the last entry it was using in the summary table...So it is still issuing the query for records after 2021. Kind of thought that might happen but it was to late last Friday to do anything about it. Will be working with the folks that support the Oracle database that is collecting all of the data in the morning. Hopefully it won't take much to "fix" it. Thanks for the different ideas. Curt Magura Lockheed Martin EIS Gaithersburg, Md. 301-240-6305 -Original Message- From: Don France (TSMnews) [mailto:[EMAIL PROTECTED]] Sent: Monday, April 01, 2002 4:59 PM To: [EMAIL PROTECTED] Subject: Re: Purge Summary Table Curtis, Try setting summaryretention to 1, stop the server, change system date to 2 days later than the bad date, start dsmserv, ACCEPT DATE -- all of this with sessions and schedules disabled, to prevent further records; after purge processing, stop the server, reset system date, start dsmserv, set retention to desired interval, maybe 30 --- did you already do an ACCEPT DATE cmd (after the accidental time-source problem)? This sounds like you need a debug command to clear up; did you get any help from TSM Support folks? I'd guess other folks have this problem, but might not notice until they run an open-ended date on their query (like TDS does). Regards, Don Don France Technical Architect - Tivoli Storage Manager Professional Association of Contract Employees (P.A.C.E.) San Jose, CA (408) 257-3037 [EMAIL PROTECTED] - Original Message - From: "Magura, Curtis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 28, 2002 5:28 AM Subject: Purge Summary Table > I plan to call the support center in a bit but thought I'd throw this out to > the experts and see if anyone has any thoughts. > > TSM Server 4.2.1.7 on AIX 4.3.3 ML6. > > The time source that we use for our machines got set to the year 2021 > recently (that's another whole story!). As a result we have a record in the > summary table from 2021. We are in the process of setting up TDS reporting > and it turns out that is uses the summary table as part of the input. The > command below gets issues when you run the TDS loader. > > 03/28/2002 06:52:29 ANR2017I Administrator ISMBATCH issued command: DEFINE > CURSOR C3330188 SQL="SELECT * from SUMMARY where END_TIME >= '2021-08-18 > 06:02:19' order by END_TIME" > > As a result a majority of the cubes that get built as part of TDS are empty. > We have been running with the summaryretention set to 30. I reset it to 0 > hoping it would reset the table. No luck. Started and stopped TSM while it > was set to 0...still no luck. > > Looking for a way to purge the record from the database. Here's the > offending record: > > START_TIME: 2021-08-18 06:00:06.00 > END_TIME: 2021-08-18 06:02:19.00 > ACTIVITY: STGPOOL BACKUP > NUMBER: 440 > ENTITY: BACKUPPOOL -> OFFSITE > COMMMETH: > ADDRESS: > SCHEDULE_NAME: COPY_BACKUPPOOL_OFFSITE > EXAMINED: 162 > AFFECTED: 162 > FAILED: 0 > BYTES: 28143616 > IDLE: 0 > MEDIAW: 62 > PROCESSES: 1 > SUCCESSFUL: YES > VOLUME_NAME: > DRIVE_NAME: > LIBRARY_NAME: > LAST_USE: > > Thoughts? > > Curt Magura > Lockheed Martin EIS > Gaithersburg, Md. > 301-240-6305
Re: Purge Summary Table
Curtis, Try setting summaryretention to 1, stop the server, change system date to 2 days later than the bad date, start dsmserv, ACCEPT DATE -- all of this with sessions and schedules disabled, to prevent further records; after purge processing, stop the server, reset system date, start dsmserv, set retention to desired interval, maybe 30 --- did you already do an ACCEPT DATE cmd (after the accidental time-source problem)? This sounds like you need a debug command to clear up; did you get any help from TSM Support folks? I'd guess other folks have this problem, but might not notice until they run an open-ended date on their query (like TDS does). Regards, Don Don France Technical Architect - Tivoli Storage Manager Professional Association of Contract Employees (P.A.C.E.) San Jose, CA (408) 257-3037 [EMAIL PROTECTED] - Original Message - From: "Magura, Curtis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 28, 2002 5:28 AM Subject: Purge Summary Table > I plan to call the support center in a bit but thought I'd throw this out to > the experts and see if anyone has any thoughts. > > TSM Server 4.2.1.7 on AIX 4.3.3 ML6. > > The time source that we use for our machines got set to the year 2021 > recently (that's another whole story!). As a result we have a record in the > summary table from 2021. We are in the process of setting up TDS reporting > and it turns out that is uses the summary table as part of the input. The > command below gets issues when you run the TDS loader. > > 03/28/2002 06:52:29 ANR2017I Administrator ISMBATCH issued command: DEFINE > CURSOR C3330188 SQL="SELECT * from SUMMARY where END_TIME >= '2021-08-18 > 06:02:19' order by END_TIME" > > As a result a majority of the cubes that get built as part of TDS are empty. > We have been running with the summaryretention set to 30. I reset it to 0 > hoping it would reset the table. No luck. Started and stopped TSM while it > was set to 0...still no luck. > > Looking for a way to purge the record from the database. Here's the > offending record: > > START_TIME: 2021-08-18 06:00:06.00 > END_TIME: 2021-08-18 06:02:19.00 > ACTIVITY: STGPOOL BACKUP > NUMBER: 440 > ENTITY: BACKUPPOOL -> OFFSITE > COMMMETH: > ADDRESS: > SCHEDULE_NAME: COPY_BACKUPPOOL_OFFSITE > EXAMINED: 162 > AFFECTED: 162 > FAILED: 0 > BYTES: 28143616 > IDLE: 0 > MEDIAW: 62 > PROCESSES: 1 > SUCCESSFUL: YES > VOLUME_NAME: > DRIVE_NAME: > LIBRARY_NAME: > LAST_USE: > > Thoughts? > > Curt Magura > Lockheed Martin EIS > Gaithersburg, Md. > 301-240-6305
Re: Purge Summary Table
You might try... disabling your various commmethods so sessions can't start/stop and disable your scheduler for your processes so nothing gets logged to the summary table during this process. Then set your system time to 2 months after the bad record, make sure that record expires off, set the time back to normal, then quit your session. Hopefully it won't log your session to the summary table until your session ends. Or, at least, that's how the accounting log works. It might be worth a shot. Unless the Summary table is purged by a process? I didn't see anything about that in the manual. Going from the other end, and I haven't worked with it, but maybe there's a way to change how TDS constructs its report or retrieves its data? Alex Paschal Storage Administrator Freightliner, LLC (503) 745-6850 phone/vmail -Original Message- From: Magura, Curtis [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 28, 2002 5:28 AM To: [EMAIL PROTECTED] Subject: Purge Summary Table I plan to call the support center in a bit but thought I'd throw this out to the experts and see if anyone has any thoughts. TSM Server 4.2.1.7 on AIX 4.3.3 ML6. The time source that we use for our machines got set to the year 2021 recently (that's another whole story!). As a result we have a record in the summary table from 2021. We are in the process of setting up TDS reporting and it turns out that is uses the summary table as part of the input. The command below gets issues when you run the TDS loader. 03/28/2002 06:52:29 ANR2017I Administrator ISMBATCH issued command: DEFINE CURSOR C3330188 SQL="SELECT * from SUMMARY where END_TIME >= '2021-08-18 06:02:19' order by END_TIME" As a result a majority of the cubes that get built as part of TDS are empty. We have been running with the summaryretention set to 30. I reset it to 0 hoping it would reset the table. No luck. Started and stopped TSM while it was set to 0...still no luck. Looking for a way to purge the record from the database. Here's the offending record: START_TIME: 2021-08-18 06:00:06.00 END_TIME: 2021-08-18 06:02:19.00 ACTIVITY: STGPOOL BACKUP NUMBER: 440 ENTITY: BACKUPPOOL -> OFFSITE COMMMETH: ADDRESS: SCHEDULE_NAME: COPY_BACKUPPOOL_OFFSITE EXAMINED: 162 AFFECTED: 162 FAILED: 0 BYTES: 28143616 IDLE: 0 MEDIAW: 62 PROCESSES: 1 SUCCESSFUL: YES VOLUME_NAME: DRIVE_NAME: LIBRARY_NAME: LAST_USE: Thoughts? Curt Magura Lockheed Martin EIS Gaithersburg, Md. 301-240-6305
Purge Summary Table
I plan to call the support center in a bit but thought I'd throw this out to the experts and see if anyone has any thoughts. TSM Server 4.2.1.7 on AIX 4.3.3 ML6. The time source that we use for our machines got set to the year 2021 recently (that's another whole story!). As a result we have a record in the summary table from 2021. We are in the process of setting up TDS reporting and it turns out that is uses the summary table as part of the input. The command below gets issues when you run the TDS loader. 03/28/2002 06:52:29 ANR2017I Administrator ISMBATCH issued command: DEFINE CURSOR C3330188 SQL="SELECT * from SUMMARY where END_TIME >= '2021-08-18 06:02:19' order by END_TIME" As a result a majority of the cubes that get built as part of TDS are empty. We have been running with the summaryretention set to 30. I reset it to 0 hoping it would reset the table. No luck. Started and stopped TSM while it was set to 0...still no luck. Looking for a way to purge the record from the database. Here's the offending record: START_TIME: 2021-08-18 06:00:06.00 END_TIME: 2021-08-18 06:02:19.00 ACTIVITY: STGPOOL BACKUP NUMBER: 440 ENTITY: BACKUPPOOL -> OFFSITE COMMMETH: ADDRESS: SCHEDULE_NAME: COPY_BACKUPPOOL_OFFSITE EXAMINED: 162 AFFECTED: 162 FAILED: 0 BYTES: 28143616 IDLE: 0 MEDIAW: 62 PROCESSES: 1 SUCCESSFUL: YES VOLUME_NAME: DRIVE_NAME: LIBRARY_NAME: LAST_USE: Thoughts? Curt Magura Lockheed Martin EIS Gaithersburg, Md. 301-240-6305
