Voice of the DBA

Author: way0utwest

  • SQL Server on RDS

    Amazon RDS
    SQL Server 2008 R2 is now on RDS

    A database service in the cloud.

    Imagine being able to connect to SQL Server on a remote machine, without having to administer the underlying OS, and without having to change the database code that you build against your local instance? Amazon has provided that with it’s Relational Database Service (RDS) for Oracle and MySQL, and has just added SQL Server 2008 R2 as well. Red Gate Software and SQLServerCentral are happy to partner with Amazon to announce the launch of this service.

    RDS gives you the chance to deploy a SQL Server instance that’s essentially the same as the one you install on your local servers, allowing you to developer and test the same code you will deploy to the cloud, without compromising the features that are available. There are a few restrictions at the instance level since you don’t have access to the underlying host OS, but the benefit is that you don’t need to administer the OS, and if you just need a database service for an application, this  is one way to get it setup and running quickly. Specify a few parameters, and Amazon will handle the rest. In a few minutes, you have an instance that you can connect to and use. We’ve tested the Red Gate Software tools against RDS and they work just like they work on any other instance.

    The cloud isn’t for every database, and this service won’t work for every type of application, but for many people that need a database and a simple web application deployed, this is a great way to get started with a minimal investment in your public infrastructure. And you can leverage your local SQL Server 2008 R2 Developer instance to develop code that will work, without worrying about the services in the cloud.

    It’s a little scary to me to think about letting go of the control of managing my own database, but there are good capacity limits, security improves, and for many applications, just having a database service available would work great. And they’ll even handle the backups automatically for your new database. How many system administrators have you worked with that didn’t do that?

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • The Colocated Dangers

    Titanic Poster
    It’s not “if”, but “when” you will have a disaster.

    We went down.

    It was quite a surprise for me, and something that hasn’t happened in a long time. It wasn’t for long, but a month ago, there was a period of time when SQLServerCentral was down. It’s also one of the very few times it’s happened since I was in charge of the servers. The exact reason was something to do with out hardware, and it was fixed relatively quickly by our hosting provider.

    Early on in the site’s history we had a few hiccups. I was the one that drove out to a co-location facility to replace hardware or fix something that was broken. There were a few times where all that was required was a reboot, but we didn’t have the “remote hands” service available at a few of our hosting facilities. Fortunately for me I had an understanding boss that would allow me to flex and extend my lunch time during these emergencies.

    Since Red Gate purchased SQLServerCentral, we’ve had excellent uptime. A few outages for upgrades of the site, a minor DNS issue, and a few hiccups from maintenance by our hosting facility, but all very short. This hour-or-so long outage was the first unplanned outage in years. However it reminded me of a somethings: it’s not if a disaster will occur, but when it will occur?

    Putting all your data (and the servers it lives on) in one place is the fact of life that most of us have to live with, but we ought to have some idea of a DR plan if our data center goes down, or our hosting company has an issue. It might not be a thoroughly documented plan, but it ought to be a thoroughly thought out one.

    At least if expect your enterprise to continue to function during the disaster and your employment to continue after.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • T-SQL Tuesday #30 – Ethics

    TSQL2sDay150x150This month the topic is hosted by Chris Shaw, and his topic is ethics.

    The blog party is the second Tuesday of each month. There is a theme and it is hosted by a different blogger every month. I’ve got a complete list of topics on my blog if you want to read about the past entries.

    It was started by Adam Machanic and if you want to host one, let him know. It can be fun, though a little busy as you compile a summary of the posts from the month.

    Ethics

    I thought this was a great topic, and I’ve actually written on it before. Chris asks a few questions about ethics and they are good ones. I’d like to think that most people have a good code of ethics, but I also think many people haven’t really thought through what their ethics are on this situation. You should do your job, and do what you’re told, but I think breaking the law, or performing an action that violates your moral principles is a no-no.

    However when you get into more subtle issues, like the one Chris talks about with regard to security, what do you do?

    Overall you have to follow your moral compass and use The Test.

    • If you have any doubt about what you’ve been asked to do, seek a second opinion, and get a confirmation from your boss (or their boss) in writing.
    • If you are sure it’s wrong, don’t do it, give you reasons, and let them get someone else to do it.
    • If it’s illegal, you should report it.

    I know sometimes this puts you in a bad situation, and you may fear for your job. That’s natural, and understandable, especially if you are the sole breadwinner for your family.

    However you also have to live with your actions, and they reflect on your soul daily. I would ask that you make the right decision, even when it’s not the most popular, profitable, or palatable one.

  • Finding the Default Trace File

    A post more for me than for anyone else, since I’ll look for something in the default trace and I often need this snippet of code:

    select path 
 from sys.traces 
 where is_default = 1

    That returns something like this:

    path

    ————————————————————————-

    C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Log\log_92.trc

    This is the current file being used by the trace, which allows me to then look into the file for some event.

    From here, I usually start running a query like this:

    select 
   e.name as eventclass
 , t.textdata
 , t.starttime
 , t.error 
 , t.hostname
 , t.ntusername
 , t.ntdomainname
 , t.clientprocessid
 , t.applicationname
 , t.loginname
 , t.spid
 from fn_trace_gettable('C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Log\log_92.trc', default) t
  inner join sys.trace_events e 
     on t.eventclass = e.trace_event_id 
  where eventclass = xx

    In this query, I take the output from the first query and use that as the FROM file and then include an event class number in the WHERE clause. I needed this today, running a check for the latest DBCC, and so I used the class 116.

    You can get a list of event classes here: Trace Event Classes