Pros and Cons of starting the SQL services with a user account instead of the lsm

What are the pros and cons of starting the SQL services (MSSQLSERVER &
SQLAgent) with a domain wide user account instead of using the Local
System Account that does not have network access. To me it would seem
more secure to start the services using an account that cannot access
the network.
Thanks
MarcosI suspect that using a different account might force you to run the ole db
drivers for linked servers inside the same process as sql server, check my
earlier thread on october 21.
I am not sure about this but no one has given me a clear answer...
Otherwise we're using different accounts to run our sql servers without
problems (i think, i'm not the one that set up the servers...)
"Marcos Marrero" wrote:
> What are the pros and cons of starting the SQL services (MSSQLSERVER &
> SQLAgent) with a domain wide user account instead of using the Local
> System Account that does not have network access. To me it would seem
> more secure to start the services using an account that cannot access
> the network.
> Thanks
> Marcos
>

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.