Properties

Why is it on some sql server 2000 machines - sp3a, running windows 2000,
all being similar in hardware setup, speed, memory, etc that it really
takes long to return a properties screen or simply right click to
disconnect? Curious, any ideas?
Thanks
*** Sent via Developersdex http://www.examnotes.net ***
Don't just participate in USENET...get rewarded for it!"Dave Brooks" <dbrooks@.neca.org> wrote in message
news:uW9y8Jo6DHA.1636@.TK2MSFTNGP12.phx.gbl...

quote:

---

> Why is it on some sql server 2000 machines - sp3a, running windows 2000,
> all being similar in hardware setup, speed, memory, etc that it really
> takes long to return a properties screen or simply right click to
> disconnect? Curious, any ideas?
> Thanks
>
> *** Sent via Developersdex http://www.examnotes.net ***
> Don't just participate in USENET...get rewarded for it!

---

If you're talking about slow access through Enterprise Manager, then one
cause could be that there are databases on the server which are set to
auto-close; another possibility is that you have ODBC tracing enabled.
Simon

Proper way to backup and restore Broker-Enabled database

For developers, we often have a need to backup a production database and restore it on local or integration machines. This production database is enabled for service broker and operates at a relatively high traffic level. When the database is backed up, the size is nearly 12GB; when SET NEW_BROKER is subsequently executed on the restored database, the size goes down to about 800MB. It appears that most of this is residing in the xmit queue. So, my question is: how best to backup a production database with queues activated, etc. without ending up with a 12GB backup?

Thanks.

There is no way to back up the database without saving the data. A full backup is all or nothing. If you want to shrink the database, as you say, you need to do the post-processing step of NEW_BROKER. If other folks need to use the database, you should always be doing NEW_BROKER. There should not be more than one copy of a database with the same broker instance ID running.

-mike

|||Move your production data into a separate filgroup and backup only that filegroup. The Service Broker xmit queue will always reside on the primary filgroup.

Proper way to backup and restore Broker-Enabled database

For developers, we often have a need to backup a production database and restore it on local or integration machines. This production database is enabled for service broker and operates at a relatively high traffic level. When the database is backed up, the size is nearly 12GB; when SET NEW_BROKER is subsequently executed on the restored database, the size goes down to about 800MB. It appears that most of this is residing in the xmit queue. So, my question is: how best to backup a production database with queues activated, etc. without ending up with a 12GB backup?

Thanks.

There is no way to back up the database without saving the data. A full backup is all or nothing. If you want to shrink the database, as you say, you need to do the post-processing step of NEW_BROKER. If other folks need to use the database, you should always be doing NEW_BROKER. There should not be more than one copy of a database with the same broker instance ID running.

-mike

|||Move your production data into a separate filgroup and backup only that filegroup. The Service Broker xmit queue will always reside on the primary filgroup.