Re: TSM TDP Oracle - Expiration Opinions
On Wed, Apr 15, 2009 at 12:51 AM, Grigori Solonovitch g.solonovi...@bkme.com wrote: Unfortunately, command CONFIGURE is a global parameter. It means it makes changes in RMAN catalog. To have three different global parameters you need to have three different RMAN catalogs, but I really do not know how to manage backups in this case. While this is true (CONFIGURE does change in the RMAN catalog), you can overcome this by putting the desired CONFIGURE statement in your RMAN scripts, before you run the DELETEs. Steve -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Hart, Charles A Sent: Tuesday, April 14, 2009 4:18 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM TDP Oracle - Expiration Opinions Thank you for the detailed response, Grigori. So if you have to maintain 3 diff retentions per DB can you have multiple Recovery Windows per DB in RMAN? Unfortunately we need a 21Day, 90Day and yes 10YR (I know - recover what?) Regards, Charles -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Grigori Solonovitch Sent: Tuesday, April 14, 2009 1:26 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM TDP Oracle - Expiration Opinions Hello Everybody, I have no problems at all with Oracle+RMAN+TDPO+TSM environment. I have: 1) dedicated nodes for database backups, separated from file system backups (for example, LPAR05 for files and LPAR05_ORA for databases on logical partition LPAR05); 2) dedicated management class and copy group for database backups: PolicyPolicy Mgmt Copy VerVer Retain Retain Domain Set ClassGroup Data Data Extra Only Name Name Name NameExists Deleted Ver Version - - - - --- --- AIX ACTIVE DBLPAR05 STANDARDNo Limit0 31 0 Note that exact setup for copy group is important. 3) CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 31 ones for each database from RMAN prompt (very important); 4) full online backup for each database twice per month and incremental backups all other days (just to reduce recovery time - less number of incremental backups is required); 5) delete noprompt obsolete; in RMAN backup script (after completion of full or incremental backups); 6) daily for each database in RMAN script (activated as cron-job) crosscheck backup; list expired backup summary; delete noprompt expired backup; delete noprompt obsolete; after completion of all full or incremental backups. RMAN and TSM are maintaining data expiry period 31 days carefully for each database. I am really able to recover any database to any point in time up to 31 days back and I never run tdposync to remove obsolete or expired backups. Kindest regards, Grigori G. Solonovitch Senior Technical Architect Information Technology Bank of Kuwait and Middle East http://www.bkme.com Phone: (+965) 2231-2274 Mobile: (+965) 99798073 E-Mail: g.solonovi...@bkme.com Please consider the environment before printing this Email -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of antwoneeter Sent: Friday, April 10, 2009 8:37 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM TDP Oracle - Expiration Opinions I'm having similar TDP (Oracle SharePoint) file space expiration problems as well. I'm about to open a call with IBM on this, but can you check the act log to see what I'm seeing? You'll need to dig into the actual expiration process. Try running this (replace NODE_NAME and adsmorc with your tdp file space name) 'q act begind=-14 endd=today s=expir*NODE_NAME*adsmorc' and also to verify inventory expiration is completing: 'q act begind=-14 endd=today s=expir*invent*succ' For one particular Oracle node, the \adsmorc file space is flat out skipped during expiration while another identical Oracle node has \adsmorc file space processed. The occupancy of the \adsmorc file space on the skipped node constantly grows while the processed node holds relatively steady. The other UNIX Oracle node I have shows that _sometimes_ expire inventory processes it's /Oracle_FS file space but most days it skips it! Now, I track occupancy daily. On the days expire inventory processes the /Oracle_FS (evidence in the act log), the occupancy shrinks indicating this the TSM server is doing it's job. All the other days that it skips it, it grows. To me at this point, this is a bug. We're at Server v5.4.3.0, BAC 5.5.1.0, DP for Oracle 5.4.1.0. And if you're wondering, yes, backdel is enabled on all the nodes. It would be great to see what you guys find on your systems
Re: TSM TDP Oracle - Expiration Opinions
Hello Everybody, I have no problems at all with Oracle+RMAN+TDPO+TSM environment. I have: 1) dedicated nodes for database backups, separated from file system backups (for example, LPAR05 for files and LPAR05_ORA for databases on logical partition LPAR05); 2) dedicated management class and copy group for database backups: PolicyPolicy Mgmt Copy Ver Ver Retain Retain Domain Set ClassGroupData Data Extra Only Name Name Name NameExists Deleted Ver Version - - - - --- --- AIX ACTIVE DBLPAR05 STANDARDNo Limit0 31 0 Note that exact setup for copy group is important. 3) CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 31 ones for each database from RMAN prompt (very important); 4) full online backup for each database twice per month and incremental backups all other days (just to reduce recovery time - less number of incremental backups is required); 5) delete noprompt obsolete; in RMAN backup script (after completion of full or incremental backups); 6) daily for each database in RMAN script (activated as cron-job) crosscheck backup; list expired backup summary; delete noprompt expired backup; delete noprompt obsolete; after completion of all full or incremental backups. RMAN and TSM are maintaining data expiry period 31 days carefully for each database. I am really able to recover any database to any point in time up to 31 days back and I never run tdposync to remove obsolete or expired backups. Kindest regards, Grigori G. Solonovitch Senior Technical Architect Information Technology Bank of Kuwait and Middle East http://www.bkme.com Phone: (+965) 2231-2274 Mobile: (+965) 99798073 E-Mail: g.solonovi...@bkme.com Please consider the environment before printing this Email -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of antwoneeter Sent: Friday, April 10, 2009 8:37 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM TDP Oracle - Expiration Opinions I'm having similar TDP (Oracle SharePoint) file space expiration problems as well. I'm about to open a call with IBM on this, but can you check the act log to see what I'm seeing? You'll need to dig into the actual expiration process. Try running this (replace NODE_NAME and adsmorc with your tdp file space name) 'q act begind=-14 endd=today s=expir*NODE_NAME*adsmorc' and also to verify inventory expiration is completing: 'q act begind=-14 endd=today s=expir*invent*succ' For one particular Oracle node, the \adsmorc file space is flat out skipped during expiration while another identical Oracle node has \adsmorc file space processed. The occupancy of the \adsmorc file space on the skipped node constantly grows while the processed node holds relatively steady. The other UNIX Oracle node I have shows that _sometimes_ expire inventory processes it's /Oracle_FS file space but most days it skips it! Now, I track occupancy daily. On the days expire inventory processes the /Oracle_FS (evidence in the act log), the occupancy shrinks indicating this the TSM server is doing it's job. All the other days that it skips it, it grows. To me at this point, this is a bug. We're at Server v5.4.3.0, BAC 5.5.1.0, DP for Oracle 5.4.1.0. And if you're wondering, yes, backdel is enabled on all the nodes. It would be great to see what you guys find on your systems. In the mean time, I'm opening up that ETR. Richard Rhodes wrote: We have the same setup. TDPO backups go to separate nodes that have use their own pool. We have ongoing problems with RMAN deletes not changing the file in TSM (rman backup pieces) to inactive status, which are then removed during expiration. We don't know if it's RMAN, TDPO, or us with the problem. Our DBA's run TDPOSYNC fairly often to fix things up. Something is wrong and we just haven't had time to track it down. I have a script that queries the TSM backups table for files (rman backup pieces) that are older than our retension period. I run it once a week. Rick Gee, Norman Norman.Gee at LC.CA .GOV To Sent by: ADSM: ADSM-L at VM.MARIST.EDU Dist Stor cc Manager ADSM-L at VM.MARIST Subject .EDU Re: TSM TDP Oracle - Expiration Opinions 03/20/2009 01:27 PM Please respond to ADSM: Dist Stor Manager ADSM-L at VM.MARIST .EDU You will have to let RMAN do its job. Every RMAN backup piece and sets have unique file names and will never place a prior backup
Re: TSM TDP Oracle - Expiration Opinions
Thank you for the detailed response, Grigori. So if you have to maintain 3 diff retentions per DB can you have multiple Recovery Windows per DB in RMAN? Unfortunately we need a 21Day, 90Day and yes 10YR (I know - recover what?) Regards, Charles -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Grigori Solonovitch Sent: Tuesday, April 14, 2009 1:26 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM TDP Oracle - Expiration Opinions Hello Everybody, I have no problems at all with Oracle+RMAN+TDPO+TSM environment. I have: 1) dedicated nodes for database backups, separated from file system backups (for example, LPAR05 for files and LPAR05_ORA for databases on logical partition LPAR05); 2) dedicated management class and copy group for database backups: PolicyPolicy Mgmt Copy VerVer Retain Retain Domain Set ClassGroup Data Data Extra Only Name Name Name NameExists Deleted Ver Version - - - - --- --- AIX ACTIVE DBLPAR05 STANDARDNo Limit0 31 0 Note that exact setup for copy group is important. 3) CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 31 ones for each database from RMAN prompt (very important); 4) full online backup for each database twice per month and incremental backups all other days (just to reduce recovery time - less number of incremental backups is required); 5) delete noprompt obsolete; in RMAN backup script (after completion of full or incremental backups); 6) daily for each database in RMAN script (activated as cron-job) crosscheck backup; list expired backup summary; delete noprompt expired backup; delete noprompt obsolete; after completion of all full or incremental backups. RMAN and TSM are maintaining data expiry period 31 days carefully for each database. I am really able to recover any database to any point in time up to 31 days back and I never run tdposync to remove obsolete or expired backups. Kindest regards, Grigori G. Solonovitch Senior Technical Architect Information Technology Bank of Kuwait and Middle East http://www.bkme.com Phone: (+965) 2231-2274 Mobile: (+965) 99798073 E-Mail: g.solonovi...@bkme.com Please consider the environment before printing this Email -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of antwoneeter Sent: Friday, April 10, 2009 8:37 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM TDP Oracle - Expiration Opinions I'm having similar TDP (Oracle SharePoint) file space expiration problems as well. I'm about to open a call with IBM on this, but can you check the act log to see what I'm seeing? You'll need to dig into the actual expiration process. Try running this (replace NODE_NAME and adsmorc with your tdp file space name) 'q act begind=-14 endd=today s=expir*NODE_NAME*adsmorc' and also to verify inventory expiration is completing: 'q act begind=-14 endd=today s=expir*invent*succ' For one particular Oracle node, the \adsmorc file space is flat out skipped during expiration while another identical Oracle node has \adsmorc file space processed. The occupancy of the \adsmorc file space on the skipped node constantly grows while the processed node holds relatively steady. The other UNIX Oracle node I have shows that _sometimes_ expire inventory processes it's /Oracle_FS file space but most days it skips it! Now, I track occupancy daily. On the days expire inventory processes the /Oracle_FS (evidence in the act log), the occupancy shrinks indicating this the TSM server is doing it's job. All the other days that it skips it, it grows. To me at this point, this is a bug. We're at Server v5.4.3.0, BAC 5.5.1.0, DP for Oracle 5.4.1.0. And if you're wondering, yes, backdel is enabled on all the nodes. It would be great to see what you guys find on your systems. In the mean time, I'm opening up that ETR. Richard Rhodes wrote: We have the same setup. TDPO backups go to separate nodes that have use their own pool. We have ongoing problems with RMAN deletes not changing the file in TSM (rman backup pieces) to inactive status, which are then removed during expiration. We don't know if it's RMAN, TDPO, or us with the problem. Our DBA's run TDPOSYNC fairly often to fix things up. Something is wrong and we just haven't had time to track it down. I have a script that queries the TSM backups table for files (rman backup pieces) that are older than our retension period. I run it once a week. Rick Gee, Norman Norman.Gee at LC.CA .GOV To Sent by: ADSM: ADSM-L at VM.MARIST.EDU Dist Stor
Re: TSM TDP Oracle - Expiration Opinions
Well Response from IBM in Regards to TDPO and RMAN . When the TDPOracle backup is performed, the objects are saved on the TSM Server into the backup copy group. Each backup objects will have a unique name as this is a requirement of Oracle. This causes each object to be active on the TSM Server and as you are aware, an active backup object will never expire or be removed by any of the TSM processing. Since these objects are unique and they are never automatically expired from the TSM server (no versioning occurs), RMAN is utilized to delete the unwanted backup objects from the TSM server.. The BackDelete parameter for the TDP node should be set to Yes so that the TDP client can delete the backup files from the TSM server for the node. When performing deletions of the backups with RMAN and using the Data Protection for Oracle, there are various ways that the deletions can be performed. The TDP Oracle works with RMAN and thus it is possible to use the RMAN Global parameters for RECOVERY WINDOW or REDUNDANCY. It is also viable to use the Oracle DELETE OBSOLETE and DELETE EXPIRED and/or an RMAN script to CHANGE the backuppiece for deletion. It is very important to ensure that the same environment variables are used for the deletion as were specified for the backups. Specifically the TDPO_OPTFILE= would need to be the same as what was used during the backup, so that the TDPO_NODE, TDPO_FS and TDPO_OWNER are the same. The TDPOSYNC SYNCDB utility can be utilized when old objects remain on the TSM Server but have been removed from the RMAN catalog. Once an object is removed from the RMAN catalog, any deletion attempt will not find the object in the catalog and thus the deletion request is not processed. In this case it is necessary to run the tdposync to synchronize the RMAN repository with the data that exists on the TSM Server. During the TDPOSYNC processing, it will initially connect to SQLPLUS in order to query the RMAN catalog and pull the entire list of backuppieces stored there (placing the list within a temporary file in the temp directory). There is no specification for the target database. The query list will be for all the objects stored in the RMAN catalog. The TDPOSYNC will then connect to the TSM Server and verify the list of objects from there based on the NodeName and Filespace and Owner. The comparison is only one direction, which checks if the object that is on the TSM Server exists in the RMAN catalog. A list is output of those items that are on TSM but not within the RMAN catalog (additional objects may exist in the RMAN catalog). These objects can then be selected within TDPOSYNC and deleted from the TSM Server (note that the object are only removed from the TSM Server after expiration has been performed). When removing an Oracle database it is necessary to also remove this from the RMAN catalog. If the database and associated backups still exist within the RMAN catalog, the TDPOSYNC processing (as I noted above) will still see these backup objects as existing and thus not remove them from the TSM Server. This same scenario can exist if a database restore has occurred that causes a reset of the DB within the RMAN catalog, thus leaving the older backups within the catalog but no longer viable for restore. Again, in this case, it will be necessary to cleanup the RMAN catalog to remove these older references that are no longer valid. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of antwoneeter Sent: Friday, April 10, 2009 12:37 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM TDP Oracle - Expiration Opinions I'm having similar TDP (Oracle SharePoint) file space expiration problems as well. I'm about to open a call with IBM on this, but can you check the act log to see what I'm seeing? You'll need to dig into the actual expiration process. Try running this (replace NODE_NAME and adsmorc with your tdp file space name) 'q act begind=-14 endd=today s=expir*NODE_NAME*adsmorc' and also to verify inventory expiration is completing: 'q act begind=-14 endd=today s=expir*invent*succ' For one particular Oracle node, the \adsmorc file space is flat out skipped during expiration while another identical Oracle node has \adsmorc file space processed. The occupancy of the \adsmorc file space on the skipped node constantly grows while the processed node holds relatively steady. The other UNIX Oracle node I have shows that _sometimes_ expire inventory processes it's /Oracle_FS file space but most days it skips it! Now, I track occupancy daily. On the days expire inventory processes the /Oracle_FS (evidence in the act log), the occupancy shrinks indicating this the TSM server is doing it's job. All the other days that it skips it, it grows. To me at this point, this is a bug. We're at Server v5.4.3.0, BAC 5.5.1.0, DP for Oracle 5.4.1.0. And if you're wondering, yes, backdel is enabled on all the nodes. It would be great to see what you
Re: TSM TDP Oracle - Expiration Opinions
Hello Charles, Unfortunately, command CONFIGURE is a global parameter. It means it makes changes in RMAN catalog. To have three different global parameters you need to have three different RMAN catalogs, but I really do not know how to manage backups in this case. I am using RMAN/TSM retention period only for daily backup (31 days). For monthly backups (24 month) and yearly backups (5 years) I am using TSM archive for database dumps, prepared by export utility. It means, there is no online database backup and RMAN is not involved at all during monthly and yearly backups. Normal archive expire period is applied for monthly and yearly backups (dumps) from archive backup groups. I am very sorry, but there is small mistake in my previous message - please read: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 31 DAYS; instead of: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 31; Regards, Grigori G. Solonovitch Senior Technical Architect Information Technology Bank of Kuwait and Middle East http://www.bkme.com Phone: (+965) 2231-2274 Mobile: (+965) 99798073 E-Mail: g.solonovi...@bkme.com Please consider the environment before printing this Email -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Hart, Charles A Sent: Tuesday, April 14, 2009 4:18 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM TDP Oracle - Expiration Opinions Thank you for the detailed response, Grigori. So if you have to maintain 3 diff retentions per DB can you have multiple Recovery Windows per DB in RMAN? Unfortunately we need a 21Day, 90Day and yes 10YR (I know - recover what?) Regards, Charles -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Grigori Solonovitch Sent: Tuesday, April 14, 2009 1:26 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM TDP Oracle - Expiration Opinions Hello Everybody, I have no problems at all with Oracle+RMAN+TDPO+TSM environment. I have: 1) dedicated nodes for database backups, separated from file system backups (for example, LPAR05 for files and LPAR05_ORA for databases on logical partition LPAR05); 2) dedicated management class and copy group for database backups: PolicyPolicy Mgmt Copy VerVer Retain Retain Domain Set ClassGroup Data Data Extra Only Name Name Name NameExists Deleted Ver Version - - - - --- --- AIX ACTIVE DBLPAR05 STANDARDNo Limit0 31 0 Note that exact setup for copy group is important. 3) CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 31 ones for each database from RMAN prompt (very important); 4) full online backup for each database twice per month and incremental backups all other days (just to reduce recovery time - less number of incremental backups is required); 5) delete noprompt obsolete; in RMAN backup script (after completion of full or incremental backups); 6) daily for each database in RMAN script (activated as cron-job) crosscheck backup; list expired backup summary; delete noprompt expired backup; delete noprompt obsolete; after completion of all full or incremental backups. RMAN and TSM are maintaining data expiry period 31 days carefully for each database. I am really able to recover any database to any point in time up to 31 days back and I never run tdposync to remove obsolete or expired backups. Kindest regards, Grigori G. Solonovitch Senior Technical Architect Information Technology Bank of Kuwait and Middle East http://www.bkme.com Phone: (+965) 2231-2274 Mobile: (+965) 99798073 E-Mail: g.solonovi...@bkme.com Please consider the environment before printing this Email -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of antwoneeter Sent: Friday, April 10, 2009 8:37 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM TDP Oracle - Expiration Opinions I'm having similar TDP (Oracle SharePoint) file space expiration problems as well. I'm about to open a call with IBM on this, but can you check the act log to see what I'm seeing? You'll need to dig into the actual expiration process. Try running this (replace NODE_NAME and adsmorc with your tdp file space name) 'q act begind=-14 endd=today s=expir*NODE_NAME*adsmorc' and also to verify inventory expiration is completing: 'q act begind=-14 endd=today s=expir*invent*succ' For one particular Oracle node, the \adsmorc file space is flat out skipped during expiration while another identical Oracle node has \adsmorc file space processed. The occupancy of the \adsmorc file space on the skipped node constantly grows while the processed node holds relatively steady. The other UNIX Oracle node I have shows
TSM TDP Oracle - Expiration Opinions
I'm having similar TDP (Oracle SharePoint) file space expiration problems as well. I'm about to open a call with IBM on this, but can you check the act log to see what I'm seeing? You'll need to dig into the actual expiration process. Try running this (replace NODE_NAME and adsmorc with your tdp file space name) 'q act begind=-14 endd=today s=expir*NODE_NAME*adsmorc' and also to verify inventory expiration is completing: 'q act begind=-14 endd=today s=expir*invent*succ' For one particular Oracle node, the \adsmorc file space is flat out skipped during expiration while another identical Oracle node has \adsmorc file space processed. The occupancy of the \adsmorc file space on the skipped node constantly grows while the processed node holds relatively steady. The other UNIX Oracle node I have shows that _sometimes_ expire inventory processes it's /Oracle_FS file space but most days it skips it! Now, I track occupancy daily. On the days expire inventory processes the /Oracle_FS (evidence in the act log), the occupancy shrinks indicating this the TSM server is doing it's job. All the other days that it skips it, it grows. To me at this point, this is a bug. We're at Server v5.4.3.0, BAC 5.5.1.0, DP for Oracle 5.4.1.0. And if you're wondering, yes, backdel is enabled on all the nodes. It would be great to see what you guys find on your systems. In the mean time, I'm opening up that ETR. Richard Rhodes wrote: We have the same setup. TDPO backups go to separate nodes that have use their own pool. We have ongoing problems with RMAN deletes not changing the file in TSM (rman backup pieces) to inactive status, which are then removed during expiration. We don't know if it's RMAN, TDPO, or us with the problem. Our DBA's run TDPOSYNC fairly often to fix things up. Something is wrong and we just haven't had time to track it down. I have a script that queries the TSM backups table for files (rman backup pieces) that are older than our retension period. I run it once a week. Rick Gee, Norman Norman.Gee at LC.CA .GOV To Sent by: ADSM: ADSM-L at VM.MARIST.EDU Dist Stor cc Manager ADSM-L at VM.MARIST Subject .EDU Re: TSM TDP Oracle - Expiration Opinions 03/20/2009 01:27 PM Please respond to ADSM: Dist Stor Manager ADSM-L at VM.MARIST .EDU You will have to let RMAN do its job. Every RMAN backup piece and sets have unique file names and will never place a prior backup into an inactive status. How would you expire a RMAN backup since every backup piece is still active? Short of mass delete on filespace. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L at VM.MARIST.EDU] On Behalf Of Hart, Charles A Sent: Friday, March 20, 2009 9:30 AM To: ADSM-L at VM.MARIST.EDU Subject: TSM TDP Oracle - Expiration Opinions We currently have your Oracle TDP Clients setup as a Separate node in separate a separate domain down to the storage pool hierarchy. That said we are having challenges with DBA's and their RMAN delete scripts for various reasons. According to the TDP for DB manual its recommended to have the RMAN catalog maintain retention which I would agree with but we are little success, and end up filling up virtual tape subsystems, orphaning data etc. The enough now is to have TSM maintain the RMAN retention and the DBA's would just clean their RMAN catalog with a crosscheck and delete process. What do you? Do you let RMAN maintain Retention or TSM maintain pitfalls of either? Best Regards, Charles Hart This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message. +-- |This was sent by sam.wozn...@gmail.com via Backup
TSM TDP Oracle - Expiration Opinions
We currently have your Oracle TDP Clients setup as a Separate node in separate a separate domain down to the storage pool hierarchy. That said we are having challenges with DBA's and their RMAN delete scripts for various reasons. According to the TDP for DB manual its recommended to have the RMAN catalog maintain retention which I would agree with but we are little success, and end up filling up virtual tape subsystems, orphaning data etc. The enough now is to have TSM maintain the RMAN retention and the DBA's would just clean their RMAN catalog with a crosscheck and delete process. What do you? Do you let RMAN maintain Retention or TSM maintain pitfalls of either? Best Regards, Charles Hart This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
Re: TSM TDP Oracle - Expiration Opinions
You will have to let RMAN do its job. Every RMAN backup piece and sets have unique file names and will never place a prior backup into an inactive status. How would you expire a RMAN backup since every backup piece is still active? Short of mass delete on filespace. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Hart, Charles A Sent: Friday, March 20, 2009 9:30 AM To: ADSM-L@VM.MARIST.EDU Subject: TSM TDP Oracle - Expiration Opinions We currently have your Oracle TDP Clients setup as a Separate node in separate a separate domain down to the storage pool hierarchy. That said we are having challenges with DBA's and their RMAN delete scripts for various reasons. According to the TDP for DB manual its recommended to have the RMAN catalog maintain retention which I would agree with but we are little success, and end up filling up virtual tape subsystems, orphaning data etc. The enough now is to have TSM maintain the RMAN retention and the DBA's would just clean their RMAN catalog with a crosscheck and delete process. What do you? Do you let RMAN maintain Retention or TSM maintain pitfalls of either? Best Regards, Charles Hart This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
Re: TSM TDP Oracle - Expiration Opinions
We have the same setup. TDPO backups go to separate nodes that have use their own pool. We have ongoing problems with RMAN deletes not changing the file in TSM (rman backup pieces) to inactive status, which are then removed during expiration. We don't know if it's RMAN, TDPO, or us with the problem. Our DBA's run TDPOSYNC fairly often to fix things up. Something is wrong and we just haven't had time to track it down. I have a script that queries the TSM backups table for files (rman backup pieces) that are older than our retension period. I run it once a week. Rick Gee, Norman norman@lc.ca .GOV To Sent by: ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager ads...@vm.marist Subject .EDU Re: TSM TDP Oracle - Expiration Opinions 03/20/2009 01:27 PM Please respond to ADSM: Dist Stor Manager ads...@vm.marist .EDU You will have to let RMAN do its job. Every RMAN backup piece and sets have unique file names and will never place a prior backup into an inactive status. How would you expire a RMAN backup since every backup piece is still active? Short of mass delete on filespace. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Hart, Charles A Sent: Friday, March 20, 2009 9:30 AM To: ADSM-L@VM.MARIST.EDU Subject: TSM TDP Oracle - Expiration Opinions We currently have your Oracle TDP Clients setup as a Separate node in separate a separate domain down to the storage pool hierarchy. That said we are having challenges with DBA's and their RMAN delete scripts for various reasons. According to the TDP for DB manual its recommended to have the RMAN catalog maintain retention which I would agree with but we are little success, and end up filling up virtual tape subsystems, orphaning data etc. The enough now is to have TSM maintain the RMAN retention and the DBA's would just clean their RMAN catalog with a crosscheck and delete process. What do you? Do you let RMAN maintain Retention or TSM maintain pitfalls of either? Best Regards, Charles Hart This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
