Lets jump into a practical example of openrowset in action. A common issue among dataservers is disk space so it only makes sense to monitor for thresholds so that you can fix an issue before it becomes an emergency. Thresholds are great, and you probably have an alerting tool like HP Service Center to take care of that for you. However, what about trending and proactive issue resolution?

When you must maintain hundreds of machines, space trending is practically a requirement. You will likely want to monitor (and trend) disk space on the database level as well, and we will get to that in a separate post.

We will work off of my openrowset disk space collector found on my scripts page HERE. This procedure is meant to be executed from your central data collection point and does not need to exist everywhere.

First, my approach toward the openrowset:

Here, we figure we will try and keep everything as dynamic as possible. The only real things we need to specify are the driver and that this will be a trusted connection. We will construct the remote query dynamically in the code before openrowset and the remote instance will be passed into the instance upon execution (exec p_get_drive_details ‘HOSTNAME\INSTANCENAME’).

To setup, first create a table drive_details with columns for: Date, InstanceName, DriveLetter, TotalMB, FreeMB

After that, create the procedure and run. In our crawler, which we will discuss later, we can loop through all of our available instances (we will get into error checking later too).

Bonus: Create a view on top of your table called drive_details_recent and have it just show the last run. This way we can have a history table for trending yet quickly look up the most recent info for either displaying on a front end or to just hide old data from view.

So, I’m bored and I’m tired of looking at an empty blog, time to share some of the stuff I’ve learned (and built) over the past few years.  A lot of it will be DBA based but I’ve always been a developer at heart so they are tools to help you do the job quicker.  I’m doing a lot of cooler database development work now so hopefully once I work though some backlog I’ll get to writing about more difficult things.

First, lets talk about a crawler briefly as most of the cool stuff I’ve done is based around data collection and storage.  I imagined a single data server being a central point for collecting data from all of the other data servers.  This works for most things in the database world, especially when you don’t have the luxury of pushing a service (application) to thousands of machines.  If you are into the service side, stay tuned, the team I just joined pushes data collection to a new level so hopefully I’ll get to shed some light on the concepts I’m learning.

Now, the central point without an application sitting on every machine can be achieved with openrowset because you can assume credentials between different SQL Servers on the same network (domain can of course be different).  This requires you to enable ad-hoc queries.  The way it is setup in SQL Server is beautiful because here you only have to enable openrowset on your crawler (central point of data collection) and you can leave the settings on the other thousand data servers alone.

There, now we’ve opened the door. The next step is to get the key (which you likely already have) to all the data servers.

Typically if you are managing even a couple hundred instances you will need a DBA functional group. This is a windows domain group where you can stuff all the DBA accounts so this way, when you build out a new server, you just add that group and everyone has access. We can the run the collection instance under one of those accounts and we have access everywhere (while obeying the domain account double-hop rule); OR we can create a common SQL authentication account everywhere and use that as the method to login everywhere. Additionally we can do some tricks via BAT files, but we will talk about that another time.

There you have it, now you’re primed and ready to go. Next post I’ll talk about the queries we can run to start collecting data.

We have all heard the stories, 18 year old child prodigy builds incredible online system only to be bankrupted by some bad apple through various SQL injection attacks. Well, maybe not so dramatic but still the thought of people being able to gain complete access to your database because of one small oversight is frightening to say the least.

How do SQL injections work? Let me give you an example, you have a script that updates a row in your database which may look something like this SELECT * FROM creditcard_data WHERE mycard='".$_REQUEST['mycardnumber']."'. The goal would be to only display my information to me not everyone else in the worlds. If in the text box we submitted the following 1234' OR '1234'='1 and didn’t escape our extra slashes we would come up with the following query SELECT * FROM creditcard_data WHERE mycard='1234' OR '1234'='1234'. This would return true for every row giving us every single credit card number in the table, and a similar attack would work equally well on an INSERT, DELETE or UPDATE query.

Now the question is, how do we prevent this? PHP has two built in functions addslashes() and stripslashes(), however you must add slashes to every incoming variable and strip the slashes off of every outgoing variable. Obnoxious, no? Have no fear, I have two functions which will take care of the you forgetting factor as well as the all important cleaner code factor. On the top of every page, include the following line of code do_slashes($_REQUEST) and this line of code to the array of output from your database undo_slashes($value).

Below are are my functions, enjoy!