Re: TDP for SQL vs SQL dumps
The DBAs claim they can configure the SQL boxes to send an email with the success/failure of each db dump. As long as somebody actually monitors the emails.. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Prather, Wanda Sent: Wednesday, June 09, 2010 4:49 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TDP for SQL vs SQL dumps That works fine. Upside: No TDP for SQL license required Downside: You (the TSM admin) get no notification if those dumps fail (or accidentally get turned off). I went into a new TSM customer last year and we found 7 out of 12 SQL servers that were supposedly backing up to disk had somehow gotten the backups turned off... -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Tyree, David Sent: Wednesday, June 09, 2010 3:05 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TDP for SQL vs SQL dumps I was talking about backups with a couple of our DBAs and they mentioned using SQL scripts on the server to export the database and then use the regular TSM client to backup the exported file instead of using the TDP. They suggested building a server with a bunch of shares, one share for each of our SQL servers. Then go into each of the SQL servers and set up a script that dumps the database to share that was created for it. The dump location would have the regular TSM client running to catch all the incoming SQL files. The DBAs did some db dumps and also some log dumps as well and were able to restore them back into the server and they seemed happy with the process. Is there anything I'm missing here? It seems like a reasonable idea to me. David Tyree Interface Analyst South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
TDP for SQL vs SQL dumps
I was talking about backups with a couple of our DBAs and they mentioned using SQL scripts on the server to export the database and then use the regular TSM client to backup the exported file instead of using the TDP. They suggested building a server with a bunch of shares, one share for each of our SQL servers. Then go into each of the SQL servers and set up a script that dumps the database to share that was created for it. The dump location would have the regular TSM client running to catch all the incoming SQL files. The DBAs did some db dumps and also some log dumps as well and were able to restore them back into the server and they seemed happy with the process. Is there anything I'm missing here? It seems like a reasonable idea to me. David Tyree Interface Analyst South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: TDP for SQL vs SQL dumps
That's the way or DBA prefers it. He schedules the dumps with the database tools, and I just back up the dump files. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Tyree, David Sent: Wednesday, June 09, 2010 12:05 PM To: ADSM-L@VM.MARIST.EDU Subject: TDP for SQL vs SQL dumps I was talking about backups with a couple of our DBAs and they mentioned using SQL scripts on the server to export the database and then use the regular TSM client to backup the exported file instead of using the TDP. They suggested building a server with a bunch of shares, one share for each of our SQL servers. Then go into each of the SQL servers and set up a script that dumps the database to share that was created for it. The dump location would have the regular TSM client running to catch all the incoming SQL files. The DBAs did some db dumps and also some log dumps as well and were able to restore them back into the server and they seemed happy with the process. Is there anything I'm missing here? It seems like a reasonable idea to me. David Tyree Interface Analyst South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: TDP for SQL vs SQL dumps
That works fine. Upside: No TDP for SQL license required Downside: You (the TSM admin) get no notification if those dumps fail (or accidentally get turned off). I went into a new TSM customer last year and we found 7 out of 12 SQL servers that were supposedly backing up to disk had somehow gotten the backups turned off... -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Tyree, David Sent: Wednesday, June 09, 2010 3:05 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TDP for SQL vs SQL dumps I was talking about backups with a couple of our DBAs and they mentioned using SQL scripts on the server to export the database and then use the regular TSM client to backup the exported file instead of using the TDP. They suggested building a server with a bunch of shares, one share for each of our SQL servers. Then go into each of the SQL servers and set up a script that dumps the database to share that was created for it. The dump location would have the regular TSM client running to catch all the incoming SQL files. The DBAs did some db dumps and also some log dumps as well and were able to restore them back into the server and they seemed happy with the process. Is there anything I'm missing here? It seems like a reasonable idea to me. David Tyree Interface Analyst South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: TDP for SQL vs SQL dumps
The TDP provides a few things: - versioning - easy restore - shortest path between the live database and the final destination of the backup, thus the lowest number of things that can go wrong Everybody always prefers to do things the way they've always been done. Nobody likes changes. Dumping a db to disk, and then moving/copying that data to TSM means that you spend a bit of money on the diskspace that you need for the dumps. With big databases, that might be quite a bit of money. Also, because the dumps have to be complete before you can copy the data to TSM, there is an additional window for data-loss. It makes no sense implementing a TDP for a single 2kb database, but neither does it to dedicate an additional few TB of disk to keep your dumps and then copy them to TSM. There is no single truth, it all depends. I like TDP, I like to have all backup related logging at the TSM server, even if the backups aren't scheduled by TSM. I like to be able to tell my customers 'if it's in TSM, it can be restored'. Now how do you guarantee the quality of a two-step process? What if the intermediate disk is full, or broken, or? Who will check the consistency of the dumps? On 9 jun 2010, at 21:04, Tyree, David wrote: I was talking about backups with a couple of our DBAs and they mentioned using SQL scripts on the server to export the database and then use the regular TSM client to backup the exported file instead of using the TDP. They suggested building a server with a bunch of shares, one share for each of our SQL servers. Then go into each of the SQL servers and set up a script that dumps the database to share that was created for it. The dump location would have the regular TSM client running to catch all the incoming SQL files. The DBAs did some db dumps and also some log dumps as well and were able to restore them back into the server and they seemed happy with the process. Is there anything I'm missing here? It seems like a reasonable idea to me. David Tyree Interface Analyst South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622
Re: TDP for SQL vs SQL dumps
We have done that in the past and it worked just fine. We built the SQL Dump on our backup server (not TSM at the time) and that allowed the backup server to dump the data straight to tape. We also had a batch process to move the files to the bit bucket after they got old. The TDP is much simpler, but as long as the DBAs are happy and aware I am not worried. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Tyree, David Sent: Wednesday, June 09, 2010 2:05 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TDP for SQL vs SQL dumps I was talking about backups with a couple of our DBAs and they mentioned using SQL scripts on the server to export the database and then use the regular TSM client to backup the exported file instead of using the TDP. They suggested building a server with a bunch of shares, one share for each of our SQL servers. Then go into each of the SQL servers and set up a script that dumps the database to share that was created for it. The dump location would have the regular TSM client running to catch all the incoming SQL files. The DBAs did some db dumps and also some log dumps as well and were able to restore them back into the server and they seemed happy with the process. Is there anything I'm missing here? It seems like a reasonable idea to me. David Tyree Interface Analyst South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
