Webcast: Panic! SQL Disaster Strikes: 5 Best Practices to Recovery
No matter how much we prepare, when disaster strikes we all feel a moment of panic. For some that panic quickly passes as we get down to work to fix the problem. For others the panic continues to grow as we search for a solution. Of course back up is crucial, but in this session Sarah will provide useful real world best practices that will show how to recover from disaster and more importantly how to prepare for the inevitable. Specifically how to recover from common disaster scenarios. For example, what to do when the master database is corrupt, a drive array with half your database files fails, a hardware failure, a SQL injection attacks wipes out whole tables and many more.
Presented by: Sarah Barela
> Register Now
> Live date: 1/13/2010 at 12:00 Pacific
Happy Holidays!
We’ll be taking a break and this will be the last newsletter of 2009. We’ll be back on January 4, 2010 (sounds odd to even write it) – and of course we’ll be having the workshop on Dec 30 – the Accidental DBA. In the meantime, enjoy the holidays, have an excellent New Year and we can’t wait to tell you about some very cool things coming in 2010!
Calling All SQL Server Accidental DBAs
(We’ve corrected the registration site issues – sorry for the troubles!)
We’ll be running our virtual workshop next week – and you can attend from the comfort of your desk, your home or… well, just about anywhere! I’ll be teaching the workshop and we’ll be going through things to know, things to monitor, things to do as an Accidental DBA, one that is asked to do the DBA work, but not on a full-time basis. I really have enjoyed doing this workshop, we’ve had such great response from all sorts of DBAs, those that are looking for where to start, those looking for a few tidbits on where to go next, etc.
I hope you’ll attend – and I’ll be there to take and answer questions, live. The workshop is on December 30, so while you’re winding down the year, you can kick back and relax and put together a plan for 2010 and your servers. We’ll also be adding a free month to everyone’s membership that attends. So, if you’re a member, we’ll extend it. If not, we’ll activate you.
Hope to see you there – register today to save your spot and you’ll be all set! There’s a quick video on the site about the workshop, and you can even download the outline and all sorts of other information. Check it out here.
Evolution of the DBA? Applications, Systems and More as a DBA
Rex wrote in about the evolving DBA – wanted to share it as great food for thought –
"I think there is an emerging trend in DBA land that is akin to a split on the DBA evolutionary tree.
There is a branch of DBA’s (I’ll call it Systems DBA) that is skilled in hardware, storage, and traditional I/O, and also skilled in new things like "Security At the Virtual Layer", and "Data Proximity" disciplines. The number of SysDBA positions will eventually consolidate and move from being employed at "the business" to being employed in "the cloud". However, it will be in places that we do not yet imagine. Perhaps strategic places for a SysDBA to work would be based on proximity to an information nexus. An information nexus would be something like financial cloud concentrations in northern New Jersey. SysDBAs might work at places like NASDAQ and Verizon, instead of Savvis, or Equinix.
This information nexus could be something akin to a type of a cloud. I would guess that there will be cloud concentrations types around Financial, Health Care, Entertainment, Military, News, etc.
The Systems DBA (SysDBA) will not need to know the specifics of a particular application but will need to be able to make sure that their cloud maintains it’s throughput, has capacity, has testing and pre-production tiers, and proper security between various virtual layers. SysDBAs would be a resource to the Application DBA (AppDBA (see below)) for troubleshooting connectivity and performance when data passes/joins into other virtual layers either within the same cloud or from cloud to cloud. Eventually there will be less SysDBA jobs as the general trend is to consolidate. However, it is likely that there will be bump in this kind of job during the mass migration phase to cloud services. The tipping point of that begins the mass migration phase to cloud services will come when a standard emerges for the cloud type, and the user community trusts that the virtual layers can remain secure. The mass exodus from "private" data centers at individual business to the cloud nexus will need lots of bodies. After that boom, many of those bodies will have to specialize and become AppDBAs for the clients they migrated or perish.
The other branch, the Application DBA, will have to specialize in either particular business or discipline. They will specialize as a PeopleSoft Application DBA, or some flavor of CMS DBA. Or perhaps they will specialize in Financial Apps, Health Care Apps, or Video Apps. Primarily the AppDBA would be an agent of the client and not the cloud. As a representative of the client, the AppDBA advocates and facilitates the data needs of the business. Areas where this applies will be BI, Application Administration, Data Design, Data Facilitation (connecting data between virtual layers, and assisting the developers of the Interface) .
Business Intelligence, Stephen, as you have repeatedly mention will be a HUGE portion of this. At the same point of mass migration to the cloud, there will also need to be an army of BI/Integration focused DBA that will be used to "stitch" together the relationships between various data set(virtual layers both within and between clouds) in order to facilitate the interface needed to present the digital cloud that hangs around a physical object.
Two other areas that I think will be a big focus of the AppDBA is Data Design and Data Facilitation. . A developer working on an Android shopping app called "Eco-Shopper". Imagine that Sally scans a shampoo bar code, retrieves data for: product, health, and social network data relating around the product and herself. The allows the Sally to find out if this is the designer shampoo "X" that Sally’s friend Suzy was talking about. Sally also wasn’t sure why parabens are bad, if the manufacturer is also eco-conscious, and if there is somewhere else she might find "X". Perhaps she can get it at local store rather than Walmart. Sally will add it to her husband Sam’s Facebook shopping list and keep tabs on when he has bought it. (Sorry Sam). Perhaps Eco-Shopper sells (uploads) anonymous data to a vendor cloud type for a service that local vendors can tap into to start carrying "X".
How is the AppDBA involved in this?
Interestingly enough, Sally’s friend Suzy is the Application DBA for Eco-Shopper. Suzy knows all about Eco-Shopper’s business practices. She’s been with them 5 years now. She can not only write fast queries, but also talk to nontechnical Project Mangers and eco-Shop’s Sales team (How many drinks on Friday night at 11pm has she had with them after all?). Suzy would review the data structures and processes with developers to do things like implement/facilitate enhancements and data fixes. She would also write the technical justifications to in the procurement request sent to Senior management to purchase changes in virtual data layer access to add new data sets. As they recently have become available, perhaps she will write the spec for pulling Facebook comments and iLike data that indexed on Google so that it has closer "proximity" to Eco-Shoppers data for example to speed up the app. The specifics might be to preprocess some social network data and pull it from the "Facebook" cloud to the Eco-Shopper Cloud for members on a daily basis. Suzy will also re-organize and index the Facebook "iLike data" according to Eco-Shoppers needs.
Wow that shampoo must be good! Suzy also sees that 10 other people in her network like "X". "
What do you think? Drop me an email here.