I recently saw a list of "possibly" bad practices which included the
following. Can anyone expand as to why ?
Using DTS packages because they may be scheduled.
Using Enteprise manager to make data and schema changes
Embedding sql in applications
Thanks !"Rob C" <rwc1960@.bellsouth.net> wrote in message
news:H31Qd.2002$0y6.1071@.bignews1.bellsouth.net...
>I recently saw a list of "possibly" bad practices which included the
>following. Can anyone expand as to why ?
> Using DTS packages because they may be scheduled.
> Using Enteprise manager to make data and schema changes
> Embedding sql in applications
> Thanks !
>
>
I can't speak to the DTS package issue, but using SEM to make data and
schema changes is not always in your best interest. While it will work, the
way SEM handles schema changes may not be the quickest or best way to make
those changes in your system. As an example, turn on SQL Profiler and see
what the SEM does when you rename a table.
Embedding SQL in applications is generally verboten for a variety of
reasons. The first and foremost is that you are now creating a tightly
coupled application. What happens if you have an INSERT statement embedded
in your front-end. If you now make a schema change to the table referenced
by that INSERT statement, the INSERT may now fail. (Wrong number of columns
for example.) In an n-tier system, you should generally be looking to
achieve a loosely coupled, highly cohesive system. A second issue with
embedded SQL is that you now have to fix two programs and deploy those
programs. A third item could be security. Depending on how you have things
set up, you may have fewer and less appetizing security options if you are
using embedded SQL.
Rick Sawtell
MCT, MCSD, MCDBA|||Thanks Rick,
What about embedding SQL in VBScript within a DTS package ? Does your
opinion change ? Would you prefer that the VBScript execute a stored
proedure ?
"Rick Sawtell" <quickening@.msn.com> wrote in message
news:%232QTJepEFHA.3536@.TK2MSFTNGP15.phx.gbl...
> "Rob C" <rwc1960@.bellsouth.net> wrote in message
> news:H31Qd.2002$0y6.1071@.bignews1.bellsouth.net...
>>I recently saw a list of "possibly" bad practices which included the
>>following. Can anyone expand as to why ?
>> Using DTS packages because they may be scheduled.
>> Using Enteprise manager to make data and schema changes
>> Embedding sql in applications
>> Thanks !
>>
> I can't speak to the DTS package issue, but using SEM to make data and
> schema changes is not always in your best interest. While it will work,
> the way SEM handles schema changes may not be the quickest or best way to
> make those changes in your system. As an example, turn on SQL Profiler
> and see what the SEM does when you rename a table.
> Embedding SQL in applications is generally verboten for a variety of
> reasons. The first and foremost is that you are now creating a tightly
> coupled application. What happens if you have an INSERT statement
> embedded in your front-end. If you now make a schema change to the table
> referenced by that INSERT statement, the INSERT may now fail. (Wrong
> number of columns for example.) In an n-tier system, you should generally
> be looking to achieve a loosely coupled, highly cohesive system. A second
> issue with embedded SQL is that you now have to fix two programs and
> deploy those programs. A third item could be security. Depending on how
> you have things set up, you may have fewer and less appetizing security
> options if you are using embedded SQL.
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>|||"Rob C" <rwc1960@.bellsouth.net> wrote in message
news:tW1Qd.2007$0y6.29@.bignews1.bellsouth.net...
> Thanks Rick,
> What about embedding SQL in VBScript within a DTS package ? Does your
> opinion change ? Would you prefer that the VBScript execute a stored
> proedure ?
>
It depends. ;-)
If the DTS package is a run-once type of deal, then I have no problems with
the embedded SQL.
If however, the package is something you will run often, I would rethink it
a bit and probably go with some sprocs that are called from your DTS
package.
Rick|||Thanks Rick,
Basically, the DTS packages simply create xml files from data stored in
tables, and as each file is created, an embedded sql call is made to update
the rows that were just used to create the xml file. No user intervention
is required. The packages are run once each day.
Sound OK ?
"Rick Sawtell" <quickening@.msn.com> wrote in message
news:O9x2gj3EFHA.2828@.TK2MSFTNGP09.phx.gbl...
> "Rob C" <rwc1960@.bellsouth.net> wrote in message
> news:tW1Qd.2007$0y6.29@.bignews1.bellsouth.net...
>> Thanks Rick,
>> What about embedding SQL in VBScript within a DTS package ? Does your
>> opinion change ? Would you prefer that the VBScript execute a stored
>> proedure ?
>
> It depends. ;-)
> If the DTS package is a run-once type of deal, then I have no problems
> with the embedded SQL.
> If however, the package is something you will run often, I would rethink
> it a bit and probably go with some sprocs that are called from your DTS
> package.
>
> Rick
>
>
Showing posts with label practices. Show all posts
Showing posts with label practices. Show all posts
Monday, March 19, 2012
Bad List ?
I recently saw a list of "possibly" bad practices which included the
following. Can anyone expand as to why ?
Using DTS packages because they may be scheduled.
Using Enteprise manager to make data and schema changes
Embedding sql in applications
Thanks !"Rob C" <rwc1960@.bellsouth.net> wrote in message
news:H31Qd.2002$0y6.1071@.bignews1.bellsouth.net...
>I recently saw a list of "possibly" bad practices which included the
>following. Can anyone expand as to why ?
> Using DTS packages because they may be scheduled.
> Using Enteprise manager to make data and schema changes
> Embedding sql in applications
> Thanks !
>
>
I can't speak to the DTS package issue, but using SEM to make data and
schema changes is not always in your best interest. While it will work, the
way SEM handles schema changes may not be the quickest or best way to make
those changes in your system. As an example, turn on SQL Profiler and see
what the SEM does when you rename a table.
Embedding SQL in applications is generally verboten for a variety of
reasons. The first and foremost is that you are now creating a tightly
coupled application. What happens if you have an INSERT statement embedded
in your front-end. If you now make a schema change to the table referenced
by that INSERT statement, the INSERT may now fail. (Wrong number of columns
for example.) In an n-tier system, you should generally be looking to
achieve a loosely coupled, highly cohesive system. A second issue with
embedded SQL is that you now have to fix two programs and deploy those
programs. A third item could be security. Depending on how you have things
set up, you may have fewer and less appetizing security options if you are
using embedded SQL.
Rick Sawtell
MCT, MCSD, MCDBA|||Thanks Rick,
What about embedding SQL in VBScript within a DTS package ? Does your
opinion change ? Would you prefer that the VBScript execute a stored
proedure ?
"Rick Sawtell" <quickening@.msn.com> wrote in message
news:%232QTJepEFHA.3536@.TK2MSFTNGP15.phx.gbl...
> "Rob C" <rwc1960@.bellsouth.net> wrote in message
> news:H31Qd.2002$0y6.1071@.bignews1.bellsouth.net...
> I can't speak to the DTS package issue, but using SEM to make data and
> schema changes is not always in your best interest. While it will work,
> the way SEM handles schema changes may not be the quickest or best way to
> make those changes in your system. As an example, turn on SQL Profiler
> and see what the SEM does when you rename a table.
> Embedding SQL in applications is generally verboten for a variety of
> reasons. The first and foremost is that you are now creating a tightly
> coupled application. What happens if you have an INSERT statement
> embedded in your front-end. If you now make a schema change to the table
> referenced by that INSERT statement, the INSERT may now fail. (Wrong
> number of columns for example.) In an n-tier system, you should generally
> be looking to achieve a loosely coupled, highly cohesive system. A second
> issue with embedded SQL is that you now have to fix two programs and
> deploy those programs. A third item could be security. Depending on how
> you have things set up, you may have fewer and less appetizing security
> options if you are using embedded SQL.
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>|||"Rob C" <rwc1960@.bellsouth.net> wrote in message
news:tW1Qd.2007$0y6.29@.bignews1.bellsouth.net...
> Thanks Rick,
> What about embedding SQL in VBScript within a DTS package ? Does your
> opinion change ? Would you prefer that the VBScript execute a stored
> proedure ?
>
It depends. ;-)
If the DTS package is a run-once type of deal, then I have no problems with
the embedded SQL.
If however, the package is something you will run often, I would rethink it
a bit and probably go with some sprocs that are called from your DTS
package.
Rick|||Thanks Rick,
Basically, the DTS packages simply create xml files from data stored in
tables, and as each file is created, an embedded sql call is made to update
the rows that were just used to create the xml file. No user intervention
is required. The packages are run once each day.
Sound OK ?
"Rick Sawtell" <quickening@.msn.com> wrote in message
news:O9x2gj3EFHA.2828@.TK2MSFTNGP09.phx.gbl...
> "Rob C" <rwc1960@.bellsouth.net> wrote in message
> news:tW1Qd.2007$0y6.29@.bignews1.bellsouth.net...
>
> It depends. ;-)
> If the DTS package is a run-once type of deal, then I have no problems
> with the embedded SQL.
> If however, the package is something you will run often, I would rethink
> it a bit and probably go with some sprocs that are called from your DTS
> package.
>
> Rick
>
>
following. Can anyone expand as to why ?
Using DTS packages because they may be scheduled.
Using Enteprise manager to make data and schema changes
Embedding sql in applications
Thanks !"Rob C" <rwc1960@.bellsouth.net> wrote in message
news:H31Qd.2002$0y6.1071@.bignews1.bellsouth.net...
>I recently saw a list of "possibly" bad practices which included the
>following. Can anyone expand as to why ?
> Using DTS packages because they may be scheduled.
> Using Enteprise manager to make data and schema changes
> Embedding sql in applications
> Thanks !
>
>
I can't speak to the DTS package issue, but using SEM to make data and
schema changes is not always in your best interest. While it will work, the
way SEM handles schema changes may not be the quickest or best way to make
those changes in your system. As an example, turn on SQL Profiler and see
what the SEM does when you rename a table.
Embedding SQL in applications is generally verboten for a variety of
reasons. The first and foremost is that you are now creating a tightly
coupled application. What happens if you have an INSERT statement embedded
in your front-end. If you now make a schema change to the table referenced
by that INSERT statement, the INSERT may now fail. (Wrong number of columns
for example.) In an n-tier system, you should generally be looking to
achieve a loosely coupled, highly cohesive system. A second issue with
embedded SQL is that you now have to fix two programs and deploy those
programs. A third item could be security. Depending on how you have things
set up, you may have fewer and less appetizing security options if you are
using embedded SQL.
Rick Sawtell
MCT, MCSD, MCDBA|||Thanks Rick,
What about embedding SQL in VBScript within a DTS package ? Does your
opinion change ? Would you prefer that the VBScript execute a stored
proedure ?
"Rick Sawtell" <quickening@.msn.com> wrote in message
news:%232QTJepEFHA.3536@.TK2MSFTNGP15.phx.gbl...
> "Rob C" <rwc1960@.bellsouth.net> wrote in message
> news:H31Qd.2002$0y6.1071@.bignews1.bellsouth.net...
> I can't speak to the DTS package issue, but using SEM to make data and
> schema changes is not always in your best interest. While it will work,
> the way SEM handles schema changes may not be the quickest or best way to
> make those changes in your system. As an example, turn on SQL Profiler
> and see what the SEM does when you rename a table.
> Embedding SQL in applications is generally verboten for a variety of
> reasons. The first and foremost is that you are now creating a tightly
> coupled application. What happens if you have an INSERT statement
> embedded in your front-end. If you now make a schema change to the table
> referenced by that INSERT statement, the INSERT may now fail. (Wrong
> number of columns for example.) In an n-tier system, you should generally
> be looking to achieve a loosely coupled, highly cohesive system. A second
> issue with embedded SQL is that you now have to fix two programs and
> deploy those programs. A third item could be security. Depending on how
> you have things set up, you may have fewer and less appetizing security
> options if you are using embedded SQL.
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>|||"Rob C" <rwc1960@.bellsouth.net> wrote in message
news:tW1Qd.2007$0y6.29@.bignews1.bellsouth.net...
> Thanks Rick,
> What about embedding SQL in VBScript within a DTS package ? Does your
> opinion change ? Would you prefer that the VBScript execute a stored
> proedure ?
>
It depends. ;-)
If the DTS package is a run-once type of deal, then I have no problems with
the embedded SQL.
If however, the package is something you will run often, I would rethink it
a bit and probably go with some sprocs that are called from your DTS
package.
Rick|||Thanks Rick,
Basically, the DTS packages simply create xml files from data stored in
tables, and as each file is created, an embedded sql call is made to update
the rows that were just used to create the xml file. No user intervention
is required. The packages are run once each day.
Sound OK ?
"Rick Sawtell" <quickening@.msn.com> wrote in message
news:O9x2gj3EFHA.2828@.TK2MSFTNGP09.phx.gbl...
> "Rob C" <rwc1960@.bellsouth.net> wrote in message
> news:tW1Qd.2007$0y6.29@.bignews1.bellsouth.net...
>
> It depends. ;-)
> If the DTS package is a run-once type of deal, then I have no problems
> with the embedded SQL.
> If however, the package is something you will run often, I would rethink
> it a bit and probably go with some sprocs that are called from your DTS
> package.
>
> Rick
>
>
Bad List ?
I recently saw a list of "possibly" bad practices which included the
following. Can anyone expand as to why ?
Using DTS packages because they may be scheduled.
Using Enteprise manager to make data and schema changes
Embedding sql in applications
Thanks !
"Rob C" <rwc1960@.bellsouth.net> wrote in message
news:H31Qd.2002$0y6.1071@.bignews1.bellsouth.net...
>I recently saw a list of "possibly" bad practices which included the
>following. Can anyone expand as to why ?
> Using DTS packages because they may be scheduled.
> Using Enteprise manager to make data and schema changes
> Embedding sql in applications
> Thanks !
>
>
I can't speak to the DTS package issue, but using SEM to make data and
schema changes is not always in your best interest. While it will work, the
way SEM handles schema changes may not be the quickest or best way to make
those changes in your system. As an example, turn on SQL Profiler and see
what the SEM does when you rename a table.
Embedding SQL in applications is generally verboten for a variety of
reasons. The first and foremost is that you are now creating a tightly
coupled application. What happens if you have an INSERT statement embedded
in your front-end. If you now make a schema change to the table referenced
by that INSERT statement, the INSERT may now fail. (Wrong number of columns
for example.) In an n-tier system, you should generally be looking to
achieve a loosely coupled, highly cohesive system. A second issue with
embedded SQL is that you now have to fix two programs and deploy those
programs. A third item could be security. Depending on how you have things
set up, you may have fewer and less appetizing security options if you are
using embedded SQL.
Rick Sawtell
MCT, MCSD, MCDBA
|||Thanks Rick,
What about embedding SQL in VBScript within a DTS package ? Does your
opinion change ? Would you prefer that the VBScript execute a stored
proedure ?
"Rick Sawtell" <quickening@.msn.com> wrote in message
news:%232QTJepEFHA.3536@.TK2MSFTNGP15.phx.gbl...
> "Rob C" <rwc1960@.bellsouth.net> wrote in message
> news:H31Qd.2002$0y6.1071@.bignews1.bellsouth.net...
> I can't speak to the DTS package issue, but using SEM to make data and
> schema changes is not always in your best interest. While it will work,
> the way SEM handles schema changes may not be the quickest or best way to
> make those changes in your system. As an example, turn on SQL Profiler
> and see what the SEM does when you rename a table.
> Embedding SQL in applications is generally verboten for a variety of
> reasons. The first and foremost is that you are now creating a tightly
> coupled application. What happens if you have an INSERT statement
> embedded in your front-end. If you now make a schema change to the table
> referenced by that INSERT statement, the INSERT may now fail. (Wrong
> number of columns for example.) In an n-tier system, you should generally
> be looking to achieve a loosely coupled, highly cohesive system. A second
> issue with embedded SQL is that you now have to fix two programs and
> deploy those programs. A third item could be security. Depending on how
> you have things set up, you may have fewer and less appetizing security
> options if you are using embedded SQL.
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>
|||"Rob C" <rwc1960@.bellsouth.net> wrote in message
news:tW1Qd.2007$0y6.29@.bignews1.bellsouth.net...
> Thanks Rick,
> What about embedding SQL in VBScript within a DTS package ? Does your
> opinion change ? Would you prefer that the VBScript execute a stored
> proedure ?
>
It depends. ;-)
If the DTS package is a run-once type of deal, then I have no problems with
the embedded SQL.
If however, the package is something you will run often, I would rethink it
a bit and probably go with some sprocs that are called from your DTS
package.
Rick
|||Thanks Rick,
Basically, the DTS packages simply create xml files from data stored in
tables, and as each file is created, an embedded sql call is made to update
the rows that were just used to create the xml file. No user intervention
is required. The packages are run once each day.
Sound OK ?
"Rick Sawtell" <quickening@.msn.com> wrote in message
news:O9x2gj3EFHA.2828@.TK2MSFTNGP09.phx.gbl...
> "Rob C" <rwc1960@.bellsouth.net> wrote in message
> news:tW1Qd.2007$0y6.29@.bignews1.bellsouth.net...
>
> It depends. ;-)
> If the DTS package is a run-once type of deal, then I have no problems
> with the embedded SQL.
> If however, the package is something you will run often, I would rethink
> it a bit and probably go with some sprocs that are called from your DTS
> package.
>
> Rick
>
>
following. Can anyone expand as to why ?
Using DTS packages because they may be scheduled.
Using Enteprise manager to make data and schema changes
Embedding sql in applications
Thanks !
"Rob C" <rwc1960@.bellsouth.net> wrote in message
news:H31Qd.2002$0y6.1071@.bignews1.bellsouth.net...
>I recently saw a list of "possibly" bad practices which included the
>following. Can anyone expand as to why ?
> Using DTS packages because they may be scheduled.
> Using Enteprise manager to make data and schema changes
> Embedding sql in applications
> Thanks !
>
>
I can't speak to the DTS package issue, but using SEM to make data and
schema changes is not always in your best interest. While it will work, the
way SEM handles schema changes may not be the quickest or best way to make
those changes in your system. As an example, turn on SQL Profiler and see
what the SEM does when you rename a table.
Embedding SQL in applications is generally verboten for a variety of
reasons. The first and foremost is that you are now creating a tightly
coupled application. What happens if you have an INSERT statement embedded
in your front-end. If you now make a schema change to the table referenced
by that INSERT statement, the INSERT may now fail. (Wrong number of columns
for example.) In an n-tier system, you should generally be looking to
achieve a loosely coupled, highly cohesive system. A second issue with
embedded SQL is that you now have to fix two programs and deploy those
programs. A third item could be security. Depending on how you have things
set up, you may have fewer and less appetizing security options if you are
using embedded SQL.
Rick Sawtell
MCT, MCSD, MCDBA
|||Thanks Rick,
What about embedding SQL in VBScript within a DTS package ? Does your
opinion change ? Would you prefer that the VBScript execute a stored
proedure ?
"Rick Sawtell" <quickening@.msn.com> wrote in message
news:%232QTJepEFHA.3536@.TK2MSFTNGP15.phx.gbl...
> "Rob C" <rwc1960@.bellsouth.net> wrote in message
> news:H31Qd.2002$0y6.1071@.bignews1.bellsouth.net...
> I can't speak to the DTS package issue, but using SEM to make data and
> schema changes is not always in your best interest. While it will work,
> the way SEM handles schema changes may not be the quickest or best way to
> make those changes in your system. As an example, turn on SQL Profiler
> and see what the SEM does when you rename a table.
> Embedding SQL in applications is generally verboten for a variety of
> reasons. The first and foremost is that you are now creating a tightly
> coupled application. What happens if you have an INSERT statement
> embedded in your front-end. If you now make a schema change to the table
> referenced by that INSERT statement, the INSERT may now fail. (Wrong
> number of columns for example.) In an n-tier system, you should generally
> be looking to achieve a loosely coupled, highly cohesive system. A second
> issue with embedded SQL is that you now have to fix two programs and
> deploy those programs. A third item could be security. Depending on how
> you have things set up, you may have fewer and less appetizing security
> options if you are using embedded SQL.
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>
|||"Rob C" <rwc1960@.bellsouth.net> wrote in message
news:tW1Qd.2007$0y6.29@.bignews1.bellsouth.net...
> Thanks Rick,
> What about embedding SQL in VBScript within a DTS package ? Does your
> opinion change ? Would you prefer that the VBScript execute a stored
> proedure ?
>
It depends. ;-)
If the DTS package is a run-once type of deal, then I have no problems with
the embedded SQL.
If however, the package is something you will run often, I would rethink it
a bit and probably go with some sprocs that are called from your DTS
package.
Rick
|||Thanks Rick,
Basically, the DTS packages simply create xml files from data stored in
tables, and as each file is created, an embedded sql call is made to update
the rows that were just used to create the xml file. No user intervention
is required. The packages are run once each day.
Sound OK ?
"Rick Sawtell" <quickening@.msn.com> wrote in message
news:O9x2gj3EFHA.2828@.TK2MSFTNGP09.phx.gbl...
> "Rob C" <rwc1960@.bellsouth.net> wrote in message
> news:tW1Qd.2007$0y6.29@.bignews1.bellsouth.net...
>
> It depends. ;-)
> If the DTS package is a run-once type of deal, then I have no problems
> with the embedded SQL.
> If however, the package is something you will run often, I would rethink
> it a bit and probably go with some sprocs that are called from your DTS
> package.
>
> Rick
>
>
Wednesday, March 7, 2012
Backups Best Practices
I have a question about using sqllitespeed.
They say it is faster doing a backup, what about restores,
I have several standby servers that I do full backups on
once in a while, so I don't have to run so many trans
logs. Does it restore fast as well?
Gary
>--Original Message--
>It looks like I have been presented with 2 options for
backing up to tape.
> 1. Use veritas SQL Agent and back up the full every
<blank> days and logs every <blank> days
> 2. Backup using native SQL agent to disk and using
veritas to backup the BAK files to tape every night.
>Anyone have an opinion on which is best and why?
>.
>Yes the restores are generally faster as well.
Andrew J. Kelly
SQL Server MVP
"Gary Abbott" <anonymous@.discussions.microsoft.com> wrote in message
news:116ba01c3f5bb$cd70b130$a101280a@.phx
.gbl...
> I have a question about using sqllitespeed.
> They say it is faster doing a backup, what about restores,
> I have several standby servers that I do full backups on
> once in a while, so I don't have to run so many trans
> logs. Does it restore fast as well?
> Gary
>
> backing up to tape.
> <blank> days and logs every <blank> days
> veritas to backup the BAK files to tape every night.
They say it is faster doing a backup, what about restores,
I have several standby servers that I do full backups on
once in a while, so I don't have to run so many trans
logs. Does it restore fast as well?
Gary
>--Original Message--
>It looks like I have been presented with 2 options for
backing up to tape.
> 1. Use veritas SQL Agent and back up the full every
<blank> days and logs every <blank> days
> 2. Backup using native SQL agent to disk and using
veritas to backup the BAK files to tape every night.
>Anyone have an opinion on which is best and why?
>.
>Yes the restores are generally faster as well.
Andrew J. Kelly
SQL Server MVP
"Gary Abbott" <anonymous@.discussions.microsoft.com> wrote in message
news:116ba01c3f5bb$cd70b130$a101280a@.phx
.gbl...
> I have a question about using sqllitespeed.
> They say it is faster doing a backup, what about restores,
> I have several standby servers that I do full backups on
> once in a while, so I don't have to run so many trans
> logs. Does it restore fast as well?
> Gary
>
> backing up to tape.
> <blank> days and logs every <blank> days
> veritas to backup the BAK files to tape every night.
Backups Best Practices
It looks like I have been presented with 2 options for backing up to tape.
1. Use veritas SQL Agent and back up the full every <blank> days and logs ev
ery <blank> days
2. Backup using native SQL agent to disk and using veritas to backup the BAK
files to tape every night.
Anyone have an opinion on which is best and why?I prefer native and than pick up the files to tape. Just be aware that you
have 24 hours potential loss of data of the local backup files are lost
before they are backed up to tape. I generally let the SQL backup copy the
files to another machine directly after the backup is takes, when possible.
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"mannie" <anonymous@.discussions.microsoft.com> wrote in message
news:A03011F7-A2F7-46F9-9E10-40EE2A695832@.microsoft.com...
> It looks like I have been presented with 2 options for backing up to tape.
> 1. Use veritas SQL Agent and back up the full every <blank> days and logs
every <blank> days
> 2. Backup using native SQL agent to disk and using veritas to backup the
BAK files to tape every night.
> Anyone have an opinion on which is best and why?|||I agree with Tibor. I prefer to not have to deal with the tape agents if I
can avoid it.
Andrew J. Kelly
SQL Server MVP
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:u9hpqvW9DHA.1504@.TK2MSFTNGP12.phx.gbl...
> I prefer native and than pick up the files to tape. Just be aware that you
> have 24 hours potential loss of data of the local backup files are lost
> before they are backed up to tape. I generally let the SQL backup copy the
> files to another machine directly after the backup is takes, when
possible.
> --
> Tibor Karaszi, SQL Server MVP
> Archive at:
>
http://groups.google.com/groups?oi=...ublic.sqlserver
>
> "mannie" <anonymous@.discussions.microsoft.com> wrote in message
> news:A03011F7-A2F7-46F9-9E10-40EE2A695832@.microsoft.com...
tape.
logs
> every <blank> days
the
> BAK files to tape every night.
>|||Thanks for your input..
What is your reason for this preference?
Speed?
You are more comfortable with SQL native agent?
Reliability?
Frequency of backups required?
Are you trying to save I/O over the backup next work?
Any more areas you have to add to this list of things to consider?|||I agree with Tibor, except that I prefer to backup directly to the remote
file system using a unc name, so I don't to coordinate the file
copies...(although the backup itself will run slower and eat network
bandwidth.)
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"mannie" <anonymous@.discussions.microsoft.com> wrote in message
news:A03011F7-A2F7-46F9-9E10-40EE2A695832@.microsoft.com...
> It looks like I have been presented with 2 options for backing up to tape.
> 1. Use veritas SQL Agent and back up the full every <blank> days and logs
every <blank> days
> 2. Backup using native SQL agent to disk and using veritas to backup the
BAK files to tape every night.
> Anyone have an opinion on which is best and why?|||For me it is simple: I prefer to not have my SQL Server data in the hands on
some 3:rd party vendor. Backup from SQL Server has been around for ages and
we all know that it work and how it work... :-)
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"mannie" <anonymous@.discussions.microsoft.com> wrote in message
news:E26131EA-B631-4482-A033-B6AD4215D0B9@.microsoft.com...
> Thanks for your input..
> What is your reason for this preference?
> Speed?
> You are more comfortable with SQL native agent?
> Reliability?
> Frequency of backups required?
> Are you trying to save I/O over the backup next work?
> Any more areas you have to add to this list of things to consider?|||I am with Wayne and Tibor on this one. SQL backups (using SQLLiteSpeed for
the really big databases) to a UNC share on another machine. I then have
daily, weekly and monthly rotations to tape with the monthly tapes removed
and archived.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Wayne Snyder" <wsnyder@.computeredservices.com> wrote in message
news:%23kaRt6W9DHA.2308@.TK2MSFTNGP11.phx.gbl...
> I agree with Tibor, except that I prefer to backup directly to the remote
> file system using a unc name, so I don't to coordinate the file
> copies...(although the backup itself will run slower and eat network
> bandwidth.)
> --
> Wayne Snyder, MCDBA, SQL Server MVP
> Computer Education Services Corporation (CESC), Charlotte, NC
> www.computeredservices.com
> (Please respond only to the newsgroups.)
> I support the Professional Association of SQL Server (PASS) and it's
> community of SQL Server professionals.
> www.sqlpass.org
>
> "mannie" <anonymous@.discussions.microsoft.com> wrote in message
> news:A03011F7-A2F7-46F9-9E10-40EE2A695832@.microsoft.com...
tape.
logs
> every <blank> days
the
> BAK files to tape every night.
>|||If you have a copy of the backup on a local machine (by local meaning
accessible by UNC) you can restore in the quickest possible time where as
with tape it may be a while to get the tape loaded etc.
Andrew J. Kelly
SQL Server MVP
"mannie" <anonymous@.discussions.microsoft.com> wrote in message
news:E26131EA-B631-4482-A033-B6AD4215D0B9@.microsoft.com...
> Thanks for your input..
> What is your reason for this preference?
> Speed?
> You are more comfortable with SQL native agent?
> Reliability?
> Frequency of backups required?
> Are you trying to save I/O over the backup next work?
> Any more areas you have to add to this list of things to consider?|||Also, some of the tape software components don't support all the backup and
restore options. Especially the WITH MOVE option specifying where each file
gets placed. This is especially important with very large databases where
you will have to spread the data out on multiple devices but you don't want
to overwrite the original database.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:%23Rhsx0X9DHA.2696@.TK2MSFTNGP10.phx.gbl...
> If you have a copy of the backup on a local machine (by local meaning
> accessible by UNC) you can restore in the quickest possible time where as
> with tape it may be a while to get the tape loaded etc.
> --
> Andrew J. Kelly
> SQL Server MVP
>
> "mannie" <anonymous@.discussions.microsoft.com> wrote in message
> news:E26131EA-B631-4482-A033-B6AD4215D0B9@.microsoft.com...
>|||we are getting ready to buy sql lite speed too
testing the demo for backups is impressive wtih decrease file size and speed
restores seem to take the same amount of time as with native sql versus the
VDI Sqllitespeed
is this what other are seeing
we routinely backup DBs in the 100-250 gig range and restore them on another
server for analytical use
experimenting with ways for smallest over time window for this
things like backup to local SAN -- restore to other server across network
back to UNC path on other server -- restore from local SAN
Trying to copy such large files are a network in windows is too slow -- it
is faster to just backup in SQL and then restore in SQL or move the file
with a tape library
We soon may have a disked based backup system to try DX30 from quantum
comments on getting shortest back and restore windows
example -- a large DB we have create a 170gig backup file the backup restore
rebuild indexes on this puppy takes 15-20 hours -- we do this once a month
as that is the refresh for new data loads -- new data is about 4-6 gig a
month
"Geoff N.Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:%23nQaoqX9DHA.2832@.tk2msftngp13.phx.gbl...
> I am with Wayne and Tibor on this one. SQL backups (using SQLLiteSpeed
for
> the really big databases) to a UNC share on another machine. I then have
> daily, weekly and monthly rotations to tape with the monthly tapes removed
> and archived.
>
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Wayne Snyder" <wsnyder@.computeredservices.com> wrote in message
> news:%23kaRt6W9DHA.2308@.TK2MSFTNGP11.phx.gbl...
remote
> tape.
> logs
> the
>
1. Use veritas SQL Agent and back up the full every <blank> days and logs ev
ery <blank> days
2. Backup using native SQL agent to disk and using veritas to backup the BAK
files to tape every night.
Anyone have an opinion on which is best and why?I prefer native and than pick up the files to tape. Just be aware that you
have 24 hours potential loss of data of the local backup files are lost
before they are backed up to tape. I generally let the SQL backup copy the
files to another machine directly after the backup is takes, when possible.
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"mannie" <anonymous@.discussions.microsoft.com> wrote in message
news:A03011F7-A2F7-46F9-9E10-40EE2A695832@.microsoft.com...
> It looks like I have been presented with 2 options for backing up to tape.
> 1. Use veritas SQL Agent and back up the full every <blank> days and logs
every <blank> days
> 2. Backup using native SQL agent to disk and using veritas to backup the
BAK files to tape every night.
> Anyone have an opinion on which is best and why?|||I agree with Tibor. I prefer to not have to deal with the tape agents if I
can avoid it.
Andrew J. Kelly
SQL Server MVP
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:u9hpqvW9DHA.1504@.TK2MSFTNGP12.phx.gbl...
> I prefer native and than pick up the files to tape. Just be aware that you
> have 24 hours potential loss of data of the local backup files are lost
> before they are backed up to tape. I generally let the SQL backup copy the
> files to another machine directly after the backup is takes, when
possible.
> --
> Tibor Karaszi, SQL Server MVP
> Archive at:
>
http://groups.google.com/groups?oi=...ublic.sqlserver
>
> "mannie" <anonymous@.discussions.microsoft.com> wrote in message
> news:A03011F7-A2F7-46F9-9E10-40EE2A695832@.microsoft.com...
tape.
logs
> every <blank> days
the
> BAK files to tape every night.
>|||Thanks for your input..
What is your reason for this preference?
Speed?
You are more comfortable with SQL native agent?
Reliability?
Frequency of backups required?
Are you trying to save I/O over the backup next work?
Any more areas you have to add to this list of things to consider?|||I agree with Tibor, except that I prefer to backup directly to the remote
file system using a unc name, so I don't to coordinate the file
copies...(although the backup itself will run slower and eat network
bandwidth.)
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"mannie" <anonymous@.discussions.microsoft.com> wrote in message
news:A03011F7-A2F7-46F9-9E10-40EE2A695832@.microsoft.com...
> It looks like I have been presented with 2 options for backing up to tape.
> 1. Use veritas SQL Agent and back up the full every <blank> days and logs
every <blank> days
> 2. Backup using native SQL agent to disk and using veritas to backup the
BAK files to tape every night.
> Anyone have an opinion on which is best and why?|||For me it is simple: I prefer to not have my SQL Server data in the hands on
some 3:rd party vendor. Backup from SQL Server has been around for ages and
we all know that it work and how it work... :-)
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"mannie" <anonymous@.discussions.microsoft.com> wrote in message
news:E26131EA-B631-4482-A033-B6AD4215D0B9@.microsoft.com...
> Thanks for your input..
> What is your reason for this preference?
> Speed?
> You are more comfortable with SQL native agent?
> Reliability?
> Frequency of backups required?
> Are you trying to save I/O over the backup next work?
> Any more areas you have to add to this list of things to consider?|||I am with Wayne and Tibor on this one. SQL backups (using SQLLiteSpeed for
the really big databases) to a UNC share on another machine. I then have
daily, weekly and monthly rotations to tape with the monthly tapes removed
and archived.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Wayne Snyder" <wsnyder@.computeredservices.com> wrote in message
news:%23kaRt6W9DHA.2308@.TK2MSFTNGP11.phx.gbl...
> I agree with Tibor, except that I prefer to backup directly to the remote
> file system using a unc name, so I don't to coordinate the file
> copies...(although the backup itself will run slower and eat network
> bandwidth.)
> --
> Wayne Snyder, MCDBA, SQL Server MVP
> Computer Education Services Corporation (CESC), Charlotte, NC
> www.computeredservices.com
> (Please respond only to the newsgroups.)
> I support the Professional Association of SQL Server (PASS) and it's
> community of SQL Server professionals.
> www.sqlpass.org
>
> "mannie" <anonymous@.discussions.microsoft.com> wrote in message
> news:A03011F7-A2F7-46F9-9E10-40EE2A695832@.microsoft.com...
tape.
logs
> every <blank> days
the
> BAK files to tape every night.
>|||If you have a copy of the backup on a local machine (by local meaning
accessible by UNC) you can restore in the quickest possible time where as
with tape it may be a while to get the tape loaded etc.
Andrew J. Kelly
SQL Server MVP
"mannie" <anonymous@.discussions.microsoft.com> wrote in message
news:E26131EA-B631-4482-A033-B6AD4215D0B9@.microsoft.com...
> Thanks for your input..
> What is your reason for this preference?
> Speed?
> You are more comfortable with SQL native agent?
> Reliability?
> Frequency of backups required?
> Are you trying to save I/O over the backup next work?
> Any more areas you have to add to this list of things to consider?|||Also, some of the tape software components don't support all the backup and
restore options. Especially the WITH MOVE option specifying where each file
gets placed. This is especially important with very large databases where
you will have to spread the data out on multiple devices but you don't want
to overwrite the original database.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:%23Rhsx0X9DHA.2696@.TK2MSFTNGP10.phx.gbl...
> If you have a copy of the backup on a local machine (by local meaning
> accessible by UNC) you can restore in the quickest possible time where as
> with tape it may be a while to get the tape loaded etc.
> --
> Andrew J. Kelly
> SQL Server MVP
>
> "mannie" <anonymous@.discussions.microsoft.com> wrote in message
> news:E26131EA-B631-4482-A033-B6AD4215D0B9@.microsoft.com...
>|||we are getting ready to buy sql lite speed too
testing the demo for backups is impressive wtih decrease file size and speed
restores seem to take the same amount of time as with native sql versus the
VDI Sqllitespeed
is this what other are seeing
we routinely backup DBs in the 100-250 gig range and restore them on another
server for analytical use
experimenting with ways for smallest over time window for this
things like backup to local SAN -- restore to other server across network
back to UNC path on other server -- restore from local SAN
Trying to copy such large files are a network in windows is too slow -- it
is faster to just backup in SQL and then restore in SQL or move the file
with a tape library
We soon may have a disked based backup system to try DX30 from quantum
comments on getting shortest back and restore windows
example -- a large DB we have create a 170gig backup file the backup restore
rebuild indexes on this puppy takes 15-20 hours -- we do this once a month
as that is the refresh for new data loads -- new data is about 4-6 gig a
month
"Geoff N.Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:%23nQaoqX9DHA.2832@.tk2msftngp13.phx.gbl...
> I am with Wayne and Tibor on this one. SQL backups (using SQLLiteSpeed
for
> the really big databases) to a UNC share on another machine. I then have
> daily, weekly and monthly rotations to tape with the monthly tapes removed
> and archived.
>
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Wayne Snyder" <wsnyder@.computeredservices.com> wrote in message
> news:%23kaRt6W9DHA.2308@.TK2MSFTNGP11.phx.gbl...
remote
> tape.
> logs
> the
>
Subscribe to:
Posts (Atom)