Tag Archives: DBA

SQL Saturday NEW YORK CITY? Get a rope!

This weekend I will be speaking at SQL Saturday New York City. My last time here was two years ago for the last SQL Saturday here and I had a great time. If you are in the area come on out for some awesome speakers and a great day of learning!

Anyone remember this? No? Just me, huh? Ok.

Blogging reboot and PowerShell – Get System Information

After whining about not blogging enough, I am going to do something about this. Whether it is PowerShell or SQL, simple or complex, I know that others can benefit from my knowledge and expand their skill sets.

And you are like “That’s great Amy…where’s the PowerShell we are here for?” Ok, Ok….keep your drawers on! 😉

Recently I was tasked with gathering the system information from all of the servers at a client. Another opportunity for some PowerShell dominance.

With this script you can generate system information files and save them to a specified location. It makes sure a connection can be made to the server first, and then outputs the file. The files are created one at a time, so if you pass in a longer list of servers, you shouldn’t crash your machine. From my testing, this will take some time to run as these files don’t output quickly. Despite that, the output is worth it. This can be modified to pull your list of servers from a file or from a Central Management Server (CMS) instance.

Hope you find this useful. Happy PowerShellin’ 🙂

Podcast with SQL Data Partners

Recently I had the pleasure of meeting Carlos Chacon with SQL Data Partners and found out he had a podcast (I know…I live under a rock…with cats). He asked if I was interested in being on said podcast – ummmm…yes, please! Click here (Episode 33) if you wanna go listen to the podcast or here if they get all up in your grill about streaming stuff at the office and you wanna just read the transcript. Thanks to Carlos for the opportunity! Enjoy! 🙂

T-SQL Tuesday #73 – Those Darn Elves

t-sqltuesdaySince I have not blogged in a while, and I saw it was T-SQL Tuesday, I thought I would participate in this FOR THE FIRST TIME EVER! This month SQLBalls asks us if our SQL Servers are on the naughty or nice list. Since I have recently transitioned to a new role, I am still getting familiar with the servers and the environments I am working with. The servers of my past are but a memory, but a fresh one. I cannot even begin to think of all the different “naughty” things that were done on those servers, and how some days it felt like a losing battle. How can you fight a security or code change when you have been over ridden by management, only to have that change come back and bite you weeks or months later? The “I told you so” you might feel like popping off will fall on deaf ears and you will just be stuck fixing the problem…until it gets to be too much and you decide it is time for action.

I have done this before. The day had been a long one and I thought I was finally going home when I got drug into a call on a data issue – something was changed that shouldn’t have been. When and by whom? I didn’t know or have any way of finding this information (days later when I tried to get a backup that was several months old to validate this data from when it was deployed; there was no backup – all all – but that is a completely different issue for another time). I had my suspicions but no proof. Could have been a naughty developer elf logging in with an elevated SQL account they knew the password for. Changing the password? “Out of the question” they say. It is everywhere.

If this were the only event that had happened THAT DAY. It wasn’t. This one was production (hence the conference call). The others (yes, more than one) were pre-production. Messes that had to be cleaned up because the developer elves thought they knew better than the DBA and that they could do it on their own. This production issue was the last straw. Elves were running a muck and had to be reigned in, and they weren’t going to like it.

All the elevated permissions in the pre-production servers – gone. I didn’t care if it was a DEV server. Am I the meanest DBA in the world? So says some. Scrooge? Well, if you are into name calling and want to go there, then ok, but I get to call you names too. In this case I did not care – I was fixing things that were only broken because someone abused a privilege. It should also be said that there was some relation in the names off all the tables involved with all the issues that occurred on this day.

If I had to wag my finger and any naughty part of the SQL Server instances it would have to be at security…and I am partially to blame. It can be difficult to keep up with all the changes that happen across a large environment when it comes to assigning permissions, and if you have more than one DBA, the situation is compounded by the fact that you might not always know what the other is doing and vice versa. They might grant something that you would otherwise veto for cause. You might take care of a permissions issue one way when they would handle it differently.

While I worked on some Powershell code to pull back users from specific AD groups and incorporate alerts for some of those groups, sadly the bandwidth was not there to fully roll this out. I did however create some triggers that would send email alerts when a change was made at the server and database levels, and I made them nameless and encrypted.

 

 

The lack of a name for each of these is intentional, as is the encryption. The last thing I wanted was someone seeing these ans what they were doing, and if they had permissions to do so, disabling or dropping them to avoid having their nefarious behavior tracked. Even better would have been to put additional triggers in place to prevent the dropping of these no matter what, but I decided not to go there.

Note there is nothing there for the name for each of these – this is courtesy of the devious mind of Rob Volk. He might have too much time on his hands but this is pretty darn crafty. What you name these triggers is up to you but you have to MAKE NOTE OF WHAT THE NAME ARE!!! When I did these they were a combination of a few tabs and spaces – like “space space space tab tab” but with those actual characters. The result looks like this:

 

triggers_noname

It should go without saying use this code at your own risk and always thoroughly vet and test anything before applying it to a production environment.

If this helps further cement my meanest DBA creds then I guess I am doing it right. Sometimes the elves developers can get out of hand and it is up to Santa the DBA to make sure they know they are being watched.

 

3/12 – Webinar : Beginning Automation with Powershell

Anything I can do to reduce the time I have to spend dealing with otherwise time-sucking tasks gives me a happy. Currently, where I am, I have reduced our daily deployment process to a single Powershell cmdlet with a log file review. All the steps that normally went into each deployment (applying SQL scripts, data updates, updating the TFS task, sending an email that the deployment is done) are handled by Powershell, and the process accepts multiple deployments at the same time. As long as there are no errors in the log file for a deployment, there is nothing more to do. There’s an error? Run the same cmdlet with the rollback option.

I am still working on improving this process, from trying to get the error handling to work the way I want it to, to incorporating the automation of check-in to source control of the changes that were just applied. It is a work-in-progress that will continue to reduce the amount of time spent on what would otherwise be manual tasks.

This work led me to the idea for a session on Powershell and automation of processes. Join me and Pragmatic Works on Thursday, March 12th from the comfort of your own desk at 11am EST/10am CST for Beginning Automation with Powershell. This demo-heavy session will go over some different Powershell cmdlets and automation concepts that you can take and build upon in your own environment. Powershell is a tool that no DBA should work without. A development background is helpful but not necessary – what DBA would not want to spend a few hours writing code for a process that will save them from having to do a repetitive manual task over and over again? Automation frees up time for us to do other projects that we want to spend time on and grow our skill sets.

Have questions about this? Leave a comment below. See y’all there. 🙂

#SQLSatPhoenix This Weekend!

Both the SQLSat Austin and Albuquerque events were great – now on to Phoenix. I will be giving two sessions there – Deadlock, Block & Two Smoking Barrels: Breaking Down Blocking and Deadlocks and Making the Leap from Developer to DBA.

The first of the two is a new session for me. When it comes to blocking and deadlocks, I like to be able to identify the cause (and sometimes the culprit) and have the information needed to resolve the issue. Some methods are easier, while with others, you also have to think about the footprint of the troubleshooting itself.

With Making the Leap from Developer to DBA, this session has evolved with time and my own experiences. Anyone who is looking to transition to being a DBA full time should attend to get a real-life perspective on migrating into this role and some of the things you can look forward to.

On top of all this, I have also been invited to be part of the WIT Panel. Come join my self and some other amazing women during lunch as we share and discuss confidence and our experiences in IT.

I’m looking forward to another great SQL Saturday as well as meeting everyone in Phoenix. See y’all there! 🙂

Have you tried restarting your computer SQL Server?

Everyone at one point or another has had this experience – you have to call technical support for assistance with your operating system or an application and get posed with the question “Have you tried restarting your computer?”

“Ummm…yeah. I did that. I also power-cycled my modem, searched the internet, hacked the registry and walked counter clockwise around my chair three times. I just thought I would call you to chat.”

Anyways…

Occasionally, the same logic is what is needed to resolve issues with SQL Server – restarting the SQL Server service. While we want to think that being on a fairly up-to-date version of SQL Server means things like this don’t happen, this is still software written by humans and every possible situation cannot be accounted for in testing. Sometimes you might find documentation that this is needed. Other times, the solution to the issue you are trying to solve is not as clear.

A couple of examples of a documented situation would be when updates to the server require a reboot or when a known issue in SQL Server is able to be immediately resolved by a restart of the service. Undocumented situations that can arise from different situations can range from changes to server settings that are not taking effect to changes in database mail. I have seen both of these situations in the past year – a server setting change was affecting replication (resolved by a restart) and database mail changes not taking effect, causing mail not to be sent and the mail queue to become backed up (another lesson learned here – after the restart of the service all those messages in the queue will be sent; if you don’t want this to happen the queue needs to be cleared out prior to restart).

Unlike rebooting a computer, restarting this service (or the server itself) is typically something that is done only where the circumstances dictate that it is required. Outside of this, restarting SQL Server is typically done as a last resort and is the last thing that the DBA might think to do. Depending on the server and the processes that communicate with the SQL Server instance, the business other resources may need to be not only notified of the restart, but also why it is needed in the first place. This is made more difficult by the fact that it may be unclear whether or not the restart will solve the problem at hand.

While it might not be documented that certain changes may require a service restart, that doesn’t mean that they don’t, and those situations can be difficult to identify. In these cases, all reasonable measures had been taken without yielding the desired results. Both cases involved changes to a SQL Server instance. Making the decision to restart in cases like this is not something that should be done flippantly, but where do you draw the line at time and effort spent before pulling the trigger? My experience with these issues will dictate how I handle similar cases going forward, but as for resolving issues that I have not had experience in dealing with yet, there very well may be more painful times…followed by sound of my head hitting the desk over and over out of frustration that the solution was something so simple.

I’m Speaking – SQL Saturday #308

SQLSAT308_SPEAKING

This weekend will be my second time to speak at a SQL Saturday event, and the first time I will be doing it solo. Being a native Texan, I have to admit it is a little strange that I have never been to Houston before, but I cannot think of a more fitting reason to make the drive down there. There is also that whole Dallas vs. Houston thing….but that is an unrelated post that I think other sites have already covered ad nauseam.

My session this weekend will be on Making the Leap from Developer to DBA – a topic I am all too familiar with since I have lived it. Fulfillment of that desire to innovate and create things can be accomplished as a DBA, but that is only a small part of the role. The business depends on you to make sure data is accurate and available in a timely fashion. Developers depend on you for the same thing but also for things like deploying their code…and trying to prevent them from hanging themselves and you when you do it.

It is still not too late to sign up for the event. If you are in Texas or anywhere near Houston you should go…and come to my session. Hope to see you there. 🙂