February 19, 2010 at 8:27 am
We generally have our scheduled outages from 1 to 3 AM, and we have to schedule them at least 30 days in advance.
February 19, 2010 at 8:39 am
I think the system usage is a definite factor. However the majority of updates/patches I've done always took place at night when there was plenty of time to fix things. It's a question of risk. If I did something at 4am, I have limited time to fix things if there is an issue.
In my career, I've had these maintenance windows:
- Power plant, 1once a quarter, Sun 12:01am - 5am (or 6am)
- Small Company - Weekend deployments. Anything after Fri 5pm
- Startup - They deployed anytime, including during the day to "fix" things on the fly. (not my idea), company failed miserably
- Startup - Every Wed at 8pm MST. We had rollback scripts to reverse changes immediately if there were issues. We deployed every week for about 18 months, very few rollbacks. Most development was 1wk in length.
- Large Fortune 500, deployments Fri night.
- SSC - I've typically deployed over the weekends early. Fri night when the whole world is on weekend.
February 19, 2010 at 8:40 am
We have a maintenance window one Friday per month from 5 - 9 pm; just happens to be today. If it takes more time it is done over a weekend.
February 19, 2010 at 8:54 am
At LA_Fitness, we deploy SQL stored procedures, functions, triggers, scripts ... and web application every weekday on the average of 25 deploys daily. Developers test on development and test environment before submitting the production deploy request performed by DBA team for SQL portion and web applications by system administration team.
February 19, 2010 at 9:47 am
In my case it allways depends on the business area, because I worked in more than one industry.
In financial business it's allways been by wednesday late evening or thursday evening, and never on first week of the month. It's due to the specific needs of this area.
Now that I get back to automation industry, it only depends on start-up schedule, there's no particular day or hour, you have to be ready to deploy your piece on day and hour scheduled. Why is that? Because manufacturing plants automation depends on many people, every of them have to be ready to work and finish their own tasks inmediately, a particular case that I remember is an implementation on China. People built a power plant with new automation, then engineers wired everything and implemented low-level code. After that we started working by thursday 8pm from Buenos Aires, which is the time where engineers finished installation on China.
Regards.
February 19, 2010 at 10:12 am
Rollouts are on Sundays but not during the first week of the month (financial company). Low-risk changes are usually on Wednesday afternoons after change control meeting.
February 19, 2010 at 11:01 am
one company that I was at served up web pages from 9-5 m-f. We usually did our deployments on tuesadays and thirsdays. Development was able to get out lots of features and any patches that customers needed quickly. Another place I worked at served up web pages 24/7. Any patches could be made before 8 am m-f. We had clustered app servers so all that was required was verifying the integrity of one of the offline nodes in the cluster. If the one worked, bring down another node, copy the code one the first node to the second, bring the two patched nodes online.
With the virtualization technology out there these days it really should be possible to patch a system anytime. redundancy is the only barrier to patching a system during the daytime. Think about it you dont have the luxury of waiting during a dister recovery situation. Why should your DR process be much different than bringing a patched node online?
February 19, 2010 at 11:25 am
On my current project I have twin infrastructures. One of them is live 24/7, the other shadows. We deploy to the shadow and test the living s**t out of it, then we synch the databases and run a script that redirects the headers. The old databases are kept up to date in almost-real time and can be switched back. After a week or two we make the old live the new shadow. This takes dozens of people and hundreds of hours of mostly boring meetings but there is no noticeable downtime.
February 19, 2010 at 1:05 pm
There is something rather relaxing about doing this on a Sunday afternoon. Actually, early morning on Sunday is the best time unless it is a church website. On a few eCommerce sites I've been responsible for, I used Sunday afternoon for deployments because people don't get tensed up and things can go slightly awry without you sitting with your head in your hands calculating the cost in lost revenues whilst a database settles down for an hour-log rollback or recovery. (It once happened to me, but mercifully on a Sunday at 3AM). When everything is done, then it is off to the pub/Microbrewery for a celebration with the team and everyone gets time-off in lieu.
Actually, I agree that, nowadays, zero-downtime rollouts are often realistically achievable. It doesn't have to be expensive or labour-intensive to do this if you have the shadow in place and can do a database synchronization. It just takes a bit of planning and I've never had one go disastrously wrong since there is such an easy exit-strategy if the upgrade turns out to be a wrong-un. Actually, I rather miss those Sunday Afternoon rollouts.
Best wishes,
Phil Factor
February 19, 2010 at 1:09 pm
We were permitted maintenance windows once per month for 8hrs. This was limited to global access and online presence. Getting anything more than that required business and client sign-off.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
February 19, 2010 at 4:40 pm
Most of the Windows I get are in the middle of the night and I prefer not to implement large projects on Fridays or over the weekend. If something small goes wrong and gets missed, it could be a large issue after 2 days of no one looking at it. Also, any changes have to be approved weekly by the change control board.
February 21, 2010 at 11:02 am
Different systems different outage windows... Ours are usually a 4 hour outage window. With 1200+ servers and 300 SQL instances supporting New Zealand, Aussie, Europe and the US we have windows around the clock and on all days...
Lots of fun...
Thanks
February 21, 2010 at 3:58 pm
For customer systems we would agree each outage with the customer. Customer contracts provided for down time for security updates and general maintenance monthly, but some customers were very difficult and it would sometimes take several months to get an update applied. Others (some of our smaller customers) only cared that their systems operated between about 5pm and 10 am local time on weekdays and all day at weekends, which was when their customers would be using them, so we could have brief (less than 15 mins) outages any time between 10am and 5pm on weekdays. For in-house systems the people in the office at which the system was located would decide (everyone would be asked if it was convenient to take the system out for however long). This is great if you are small enough for it to work - but even then you will be wanting to grow out of it.
Tom
February 21, 2010 at 7:23 pm
"Downtime"? Heh... I've gotta Google that and find out what it means. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2010 at 8:50 pm
Jeff Moden (2/21/2010)
"Downtime"? Heh... I've gotta Google that and find out what it means. 😉
Let me help you out... it's the term for the free time you'll be having after implementing RBAR in all your procedures... :laugh:
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
Viewing 15 posts - 16 through 29 (of 29 total)
You must be logged in to reply to this topic. Login to reply