We are using SQL 2000
Please tell me that is it not recommended to use Enterprise manager for all
operations?
Is it OK if i use EM for all backup , restore & Maintenance Plan?
Could you please provide me the TSQL for Backup , Restore & Maintenance
Plan.
Thanking you in anticipation
regardsSee if this helps:
http://vyaskn.tripod.com/sql_enterprise_manager_or_t-sql.htm
Also check the BACKUP and RESTORE commands in SQL Server Books Online.
--
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"uppal" <compaq@.smil.co.in> wrote in message
news:eZItzydpEHA.1992@.TK2MSFTNGP09.phx.gbl...
We are using SQL 2000
Please tell me that is it not recommended to use Enterprise manager for all
operations?
Is it OK if i use EM for all backup , restore & Maintenance Plan?
Could you please provide me the TSQL for Backup , Restore & Maintenance
Plan.
Thanking you in anticipation
regards|||On Wed, 29 Sep 2004 10:02:55 +0530, uppal wrote:
>Please tell me that is it not recommended to use Enterprise manager for all
>operations?
Hi Uppal,
On the contrary. EM is very suitable for *SOME* operations. Just don't use
EM for creation of tables, views, procuderes and functions or for changing
data in your tables. Using EM to manage your SQL Server installation is
okay.
>Is it OK if i use EM for all backup , restore & Maintenance Plan?
That's one of the operations that EM excels in.
>Could you please provide me the TSQL for Backup , Restore & Maintenance
>Plan.
I have no idea. If you really need to know it, you should either look in
Books Online or you could run a trace to find out which commands are
executed when you execute these operations through EM.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||"uppal" <compaq@.smil.co.in> wrote in message
news:eZItzydpEHA.1992@.TK2MSFTNGP09.phx.gbl...
> We are using SQL 2000
> Please tell me that is it not recommended to use Enterprise manager for
all
> operations?
> Is it OK if i use EM for all backup , restore & Maintenance Plan?
>
Control.
It all comes down to how much control you want.
> Could you please provide me the TSQL for Backup , Restore & Maintenance
> Plan.
> Thanking you in anticipation
> regards
>
Showing posts with label operations. Show all posts
Showing posts with label operations. Show all posts
Friday, March 9, 2012
EM VS TSQL
Labels:
backup,
database,
enterprise,
manager,
microsoft,
mysql,
operations,
oracle,
recommended,
server,
sql,
tsql
Friday, February 17, 2012
Efficiency of SmallInt vs. SmallDatetime
I have a scheduling db (sql2000) that stores a lot of 'time' data and does
a lot of operations on this data. I'm storing event dates in a smalldatetime
field. I'm storing a 'starttime' in another smalldatetime field (eg. as
'1/1/1900 9:30') and 'endtime' in a third smalldatetime field ( eg. as
'1/1/1900 11:30').
Does anyone have any information/ideas on what performance improvements I
might see if was to instead store the 2 'time' fields as smallints (storing
number of minutes since midnight) rather than as smalldatetimes? I
understand I would halve the storage required, what about performance per
se?
Thanks,
Paul.
Hi
Every row in a Table has an overhead of about 20 bytes. Saving a byte here
or there does not help much. You have to do a lot more processing to convert
your time to smallint and back (in your code).
Have you tested the difference? Functions like dateadd and datediff and not
avilable to you if you don't use DateTime datatypes.
Regards
Mike
"Paul W" wrote:
> I have a scheduling db (sql2000) that stores a lot of 'time' data and does
> a lot of operations on this data. I'm storing event dates in a smalldatetime
> field. I'm storing a 'starttime' in another smalldatetime field (eg. as
> '1/1/1900 9:30') and 'endtime' in a third smalldatetime field ( eg. as
> '1/1/1900 11:30').
> Does anyone have any information/ideas on what performance improvements I
> might see if was to instead store the 2 'time' fields as smallints (storing
> number of minutes since midnight) rather than as smalldatetimes? I
> understand I would halve the storage required, what about performance per
> se?
> Thanks,
> Paul.
>
>
a lot of operations on this data. I'm storing event dates in a smalldatetime
field. I'm storing a 'starttime' in another smalldatetime field (eg. as
'1/1/1900 9:30') and 'endtime' in a third smalldatetime field ( eg. as
'1/1/1900 11:30').
Does anyone have any information/ideas on what performance improvements I
might see if was to instead store the 2 'time' fields as smallints (storing
number of minutes since midnight) rather than as smalldatetimes? I
understand I would halve the storage required, what about performance per
se?
Thanks,
Paul.
Hi
Every row in a Table has an overhead of about 20 bytes. Saving a byte here
or there does not help much. You have to do a lot more processing to convert
your time to smallint and back (in your code).
Have you tested the difference? Functions like dateadd and datediff and not
avilable to you if you don't use DateTime datatypes.
Regards
Mike
"Paul W" wrote:
> I have a scheduling db (sql2000) that stores a lot of 'time' data and does
> a lot of operations on this data. I'm storing event dates in a smalldatetime
> field. I'm storing a 'starttime' in another smalldatetime field (eg. as
> '1/1/1900 9:30') and 'endtime' in a third smalldatetime field ( eg. as
> '1/1/1900 11:30').
> Does anyone have any information/ideas on what performance improvements I
> might see if was to instead store the 2 'time' fields as smallints (storing
> number of minutes since midnight) rather than as smalldatetimes? I
> understand I would halve the storage required, what about performance per
> se?
> Thanks,
> Paul.
>
>
Labels:
database,
dates,
doesa,
efficiency,
event,
microsoft,
mysql,
operations,
oracle,
scheduling,
server,
smalldatetime,
smallint,
sql,
sql2000,
stores,
storing,
time
Efficiency of SmallInt vs. SmallDatetime
I have a scheduling db (sql2000) that stores a lot of 'time' data and does
a lot of operations on this data. I'm storing event dates in a smalldatetime
field. I'm storing a 'starttime' in another smalldatetime field (eg. as
'1/1/1900 9:30') and 'endtime' in a third smalldatetime field ( eg. as
'1/1/1900 11:30').
Does anyone have any information/ideas on what performance improvements I
might see if was to instead store the 2 'time' fields as smallints (storing
number of minutes since midnight) rather than as smalldatetimes? I
understand I would halve the storage required, what about performance per
se?
Thanks,
Paul.Hi
Every row in a Table has an overhead of about 20 bytes. Saving a byte here
or there does not help much. You have to do a lot more processing to convert
your time to smallint and back (in your code).
Have you tested the difference? Functions like dateadd and datediff and not
avilable to you if you don't use DateTime datatypes.
Regards
Mike
"Paul W" wrote:
> I have a scheduling db (sql2000) that stores a lot of 'time' data and does
> a lot of operations on this data. I'm storing event dates in a smalldatetime
> field. I'm storing a 'starttime' in another smalldatetime field (eg. as
> '1/1/1900 9:30') and 'endtime' in a third smalldatetime field ( eg. as
> '1/1/1900 11:30').
> Does anyone have any information/ideas on what performance improvements I
> might see if was to instead store the 2 'time' fields as smallints (storing
> number of minutes since midnight) rather than as smalldatetimes? I
> understand I would halve the storage required, what about performance per
> se?
> Thanks,
> Paul.
>
>
a lot of operations on this data. I'm storing event dates in a smalldatetime
field. I'm storing a 'starttime' in another smalldatetime field (eg. as
'1/1/1900 9:30') and 'endtime' in a third smalldatetime field ( eg. as
'1/1/1900 11:30').
Does anyone have any information/ideas on what performance improvements I
might see if was to instead store the 2 'time' fields as smallints (storing
number of minutes since midnight) rather than as smalldatetimes? I
understand I would halve the storage required, what about performance per
se?
Thanks,
Paul.Hi
Every row in a Table has an overhead of about 20 bytes. Saving a byte here
or there does not help much. You have to do a lot more processing to convert
your time to smallint and back (in your code).
Have you tested the difference? Functions like dateadd and datediff and not
avilable to you if you don't use DateTime datatypes.
Regards
Mike
"Paul W" wrote:
> I have a scheduling db (sql2000) that stores a lot of 'time' data and does
> a lot of operations on this data. I'm storing event dates in a smalldatetime
> field. I'm storing a 'starttime' in another smalldatetime field (eg. as
> '1/1/1900 9:30') and 'endtime' in a third smalldatetime field ( eg. as
> '1/1/1900 11:30').
> Does anyone have any information/ideas on what performance improvements I
> might see if was to instead store the 2 'time' fields as smallints (storing
> number of minutes since midnight) rather than as smalldatetimes? I
> understand I would halve the storage required, what about performance per
> se?
> Thanks,
> Paul.
>
>
Labels:
database,
dates,
efficiency,
event,
ime,
microsoft,
mysql,
operations,
oracle,
scheduling,
server,
smalldatetime,
smallint,
sql,
sql2000,
stores,
storing
Subscribe to:
Posts (Atom)