November 6, 2012 at 2:23 am
Hello there.
I need to run a number of scripts (which will take a number of hours) that involve data purging from a database. When I reach the point of having to run it in Production, which is a highly transactional based environment, I need to effectively to make the database inaccessible from the web frontends and other web services.
I have considered two options.
1. Set the database in SINGLE USER MODE and run the scripts
2. Uncheck the "Allow remote connections to this Server" option at server level and run the scripts.
I am also considering using sqlcmd to run the scripts from the command line as part of option 1.
I would appreciate opinions on either approach or possibly any suggestions other people may have used in similar situations that were successful.
November 6, 2012 at 2:36 am
if you are feasible to work in data center or where the physical server is kept,
you can pull out the network cable connected to your server machine .
but before check if any users are connected to sql server .
-----------------------------------------------------------------------------
संकेत कोकणे
November 6, 2012 at 4:05 am
Thanks for the suggestion but that's not possible, as Server is hosted at a remote site.
November 6, 2012 at 4:15 am
I would suggest putting the DB into single user mode and run your scripts - but you do need to send out some kind of warning to the users I would think.
Also, I would think it would be best to do that when the DB is not used (e.g. at night? 02:00 AM?) - you could schedule the jobs at that time - part of your script would be to put DB in single user mode.
Not allowing remote connections to the server sounds a little risky to me - what if something goes wrong, then you will need to make your way over to the physical box and all that?
B
November 6, 2012 at 7:23 am
Be real careful using the single user mode. If YOU lose, drop, or close your connection, on of the Web Services will grab the single connection almost immediately and you won't be able to get back in to set it to multi-user without having to find and shut down all the web services or bouncing the server with it in a maintenance mode.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2012 at 7:34 am
Personally, what I tend to do in this scenario, is set a job to run overnght using SQL Server Agent.
Rather than making alterations to SQL also, if all users are coming from a sole source (i.e. a web front end) then why not just take down the site temporarily while the work is being carried out?
You can also build steps into an Agent Job Script, which incorporates cmdexec commands to stop and start the web services before and after the job has completed...
If you're confident in the job and have rough times from testing, then it will save you having to babysit the job (set email alerts for failures).
November 6, 2012 at 7:37 am
Jeff Moden (11/6/2012)
Be real careful using the single user mode. If YOU lose, drop, or close your connection, on of the Web Services will grab the single connection almost immediately and you won't be able to get back in to set it to multi-user without having to find and shut down all the web services or bouncing the server with it in a maintenance mode.
I have considered this and it is a major concern. As part of general deployments to Production, websites are disabled but as far as I know web services remain on. I think it best therefore to disable all web sites and services and run the maintenance scripts then, outside of core hours obviously.
November 6, 2012 at 8:05 am
Could you disable all logins except one, and use that login for this maintenance?
November 6, 2012 at 8:26 am
scogeb (11/6/2012)
Could you disable all logins except one, and use that login for this maintenance?
maybe a create a logon trigger that prevents anyone from connecting unless from local connection?
then do the work, and drop the login trigger when completed?
Lowell
November 6, 2012 at 9:48 am
If the web front end/services have specific logins (as they should), then your best bet is to disable the logins
during maintenance. Or if you are using roles, you could kick them out of the roles during maintenance and add
them back in when you are done.
What is your security model like?
What is the requirement for the web front end/services? Do they need to know that maintenance is taking place
and be able to display a meaningful message?
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply