Accidental DBA

It's been nearly three months since my last post and that was not intentional. I got away from InfoPath a bit and my projects in June included a SQL migration to SQL 2008 and a SharePoint Migration to SharePoint 2010. Luckily we had a couple great consultants who did the heavy lifting to speed it up, but there were a lot of tweaks along the way and other projects tha have taken away from my time to post. On the plus side, I have all new posts in my head on new subjects.

My falling into a DBA position was not intentional. The conversation went like this:

CIO: "You are the only person here with SQL development experience. I know your DBA experience was in PROGRESS for 10 years and not SQL, but with the migrations, I need you to become the SQL DBA."

I've done a lot with SQL since 2005 - stored procedures, views, creating tables, etc., however, it was all as a developer, but the leap to being the DBA made sense as I was a DBA for Progress for over 10 years.

The first real DBA task I had to solve seems so basic, but it really took some research as I was not sure if it was a DBA task or a Network Engineering task. SQL has a design that goes out and sucks up all the memory on the server.

With a UNIX box, this was an enviromental setting and a DB setting where I would allocate a certain amount of memory for the PROGRESS DB, but I learned in SQL, this is simply a property setting.

And while it seems simple, I really questioned the wisdom of Microsoft with the out of the box setting.

In the left hand panel, select "Memory."

The parameter you want to change is "The Maximum Amount of Memory (in MB.)

The SQL default was two billion.  You are reading that correctly.  Two Billion.  Seriously.

I set ours to 8 GB (8192 MB) as that was what was recommended for a Sharepoint installation of our size.

TWO BILLION.