It’s one small word, but that one word can pack an awful powerful punch. I got a severe dose of it Friday night. No, I won’t go into the great detail that provoked this word to come to light. What I will do is recognize that it has taught me some valuable lessons especially in my every day work life.
We live in a fast paced society. Work will never cease that’s a given; when is the last time you truly stopped, looked around, and appreciated where you are at in this point in time?
I used to struggle a lot with not blogging enough, not giving back to the community enough, not submitting to speak enough, arguments with other data professionals on what is the right way to do things versus the wrong way to do things, and the list could go on and on.
I look at SQL Family and what does it truly mean to me? I take great pride in my work, the people I am involved with daily, the many issues that come up that provide new solutions waiting to be found, but SQL Family is much more than that. It is shown daily by the likes of you and me. You see it in the generosity when one of our own passes away, you see it in others who rally around a good cause, you see it when a seasoned community member takes a newbie under his/her wing to guide them, and yes you see it shown when you receive heart breaking news that we all endure through the journey we call life.
There are intervals in life when you stop and asses priorities; nothing wrong with that. You start to look at if the he said she said argument was even worth it, you blast a newbie because he made a dumb mistake due to the fact that they just didn’t know, or you get on some ego trip because you believe you are entitled to something.
There will be things you can control and there will be things you can’t control; as a data professional and proud DBA I will continue to do the best I can day in and day out. I come from the school that you work hard regardless of the situation. You won’t find perfection, you won’t find a guy who knows it all; what you will find is a guy who has a passion for the SQL Community and a passion for learning and honing is craft.
To the new community member the days will not always be perfect; heck the days you will sometimes wonder what the heck you got yourself into; enjoy the ride. Don’t beat yourself up for things you think you could have done better; learn from them and move on. Realize that SQL Family IS the people, the interaction – it is what makes it thrive.
For the ones who have been around for a long time, with as much respect as I can muster, I just implore you to realize that when life does happen outside of our SQL walls; don’t let that time go by wasted. You need to cherish every minute of it; we (me included) rush around getting to the next event, next speaking engagement, next post and if we aren’t careful we will let those outside moments pass us by.
Some will take this post as me saying not to worry about the security breach that was caused by a pointless mistake, and some will read too much into it and be wondering if I’m speaking at anyone in particular. I get how it all works, these are just intended thoughts of mine that if I can take to heart myself, then it might help me in the future to become a better data professional and DBA.
Work hard, cherish the moments, and realize that taking one day at a time is okay.
Backups are essential for a successful business model. That statement may or may spark some topics for debate, but at the end of the day if the data professional does not have a form of backup in place for his/her business needs you may, no you will, feel the pain. It may not happen today, tomorrow, next week, but you can with 100% certainty guarantee that at some point in ones career you will need a backup of your database.
Let me start off this way and ask a very simple question, “Do I have to take a backup?” The answer to that is yes, yes you do. If you are a data professional than you should care about your data enough to take a backup of it in some form or fashion.
Types of Backups
Full Backup – this type of backup contains all the data for a specific database.
Differential Backup – think about this backup as what it’s name states; contains only the data since it’s last differential base backup; you can find these backups to be smaller in nature versus the full backup methodology
Transaction Log Backup (T-Log Backup) – this type of backup is a record of all transactions that have been performed against the database since the transaction log was backed up. Most often times these types of backups are taken on a more frequent basis.
**Note** the differential and transaction log backups are both dependent upon the full backup initially being executed.
Depending on how extensive your business model is some companies will rely on backups for their disaster recovery planning. Whether you log ship, utilize always on, restore databases periodically etc. backups can and will always be an essential part of disaster recovery.
Most people don’t realize that they can tune their backups. One of the ways you can do this is by turning on some trace flags and increasing some throughput. Below are two statements you can utilize.
DBCC TRACEON (3605, -1) and DBCC TRACEON (3213, -1)
What those two statements do is tell you (in your error log) what the settings are set to
The buffer count and maxtransfersize are the two settings you want to check. Make note of what the settings are initially; then when backing up your database, whether by a stored procedure or method of choice, you can include the following code.
, BUFFERCOUNT = 800
**NOTE – never take code from the web and execute it in production. Utilize this in a testing environment to see how it performs.
Wait, what? You mean I need to test my backups. Let me pose this question another way. If you take a solid backup and you store it for a certain period of time; then how do you know if you can restore it or not? Taking backups are only half the process; I used to think early on in my career that I was golden to have a backup versus the people who don’t take backups at all. Sure that is somewhat true but the flip side to that is I was missing the bigger picture; periodically test your backups. In a perfect world an automated process would restore backups to an isolated environment then fire off an alert if you find one that could not be restored. Most shops don’t or can’t go to that extent so at the minimum periodically test your backups for validity. Not only will it prove that your backups are working but will keep your skill set honed in the restoration process.
Backups – they are important. As with anything in your data professional career; take this concept to be very important. If you aren’t backing up your data than I suggest you start. If you are backing up your data; then are you sure you can restore it? Are your backups taking forever; perhaps you can tune them? I tell you what…keep reading below and you can check out what some of my colleagues have to say around backups. Enjoy
- Julie Koesmarno: will return shortly; check back!
- Jeffrey Verheul: Speeding up your backups
- Mickey Stuewe: Transaction Log Backups for the Accidental DBA
On a SQL Collaboration Quest
Four SQL professionals gathered from the four corners of the world to share their SQL knowledge with each other and with their readers: Mickey Stuewe from California, USA, Chris Yates from Kentucky, USA, Julie Koesmarno from Canberra, Australia, and Jeffrey Verheul from Rotterdam, The Netherlands. They invite you to join them on their quest as they ask each other questions and seek out the answers in this collaborative blog series. Along the way, they will also include other SQL professionals to join in the collaboration.
This month the nod goes to none other than Jason Strate (Blog|Twitter). A few years back I sat in on one of Jason’s sessions at PASS Summit. From attending that session I found my way to his blog series called Index Black OPS which helped me tremendously, and I’ve carried some of the methodology since then.
Jason works for Pragmatic Works which is in and of itself a good company; what I’ve seen over the years that resonates with me is an extreme work ethic sprinkled in with some SQL Karaoke madness. A real down to earth guy who has a genuine love for helping people.
On this note I strongly suggest you check out his blog; he has some stellar information over there around several topics:
Don’t just limit reviewing the topics; make sure you check out the resources and publications to.
Like Jason, many SQL family members contribute on a daily basis in sharing their knowledge and helping the community grow. It’s time we (myself included) start paying homage and respect to those that give selflessly day in and day out sacrificing a lot to make our community one of the best there is.
Thanks Jason for being an impact player in our community.
Stay tuned to next month to catch Part 3 in the series of Impact Players.
This months T-SQL Tuesday is hosted by none other than Kenneth Fisher (B|T). His topic for this month revolves around security and how you manage security. There probably couldn’t be a more fitting topic; especially with the many breaches we have had lately both ones that are known and ones that are not known.
With that said I want to take this time to expound on a wider variety of topics instead of diving into specific targeted areas within SQL.
When I first heard this topic I immediately drifted to thoughts such as:
- Vendor Apps
- Breaches within
- Password Strength
Countless times over the years I have seen, reviewed, fixed, and contemplated over security within SQL that simply was an afterthought. Security whether role based, AD Groups, etc. should be worked into any project plan. If you have ever inherited a system only to review that 600 users have sysadmin access you know how detrimental that could be to the data contained within.
Being a DBA means you have great responsibility. Every single database is under your care, own it. Each day someone will be trying to access that database; at least that should be your mentality especially with any production environment.
A lot of us are creature are habits. It is very easy for a data professional to fall into the trap of becoming accustomed to daily routines. Security should not fall into this category; I repeat security should not fall into this category. Do you know who has access to your databases and why? Do you know what user accounts are tied to specific groups? If you can’t answer this then you may find yourself in this category
I like this one, how many of us validate our security measures? Do we take any proactive approaches to see just how safe our data is? Maybe you rely on an outside 3rd party to see if they can hack in; whatever the case maybe it would behoove us as a group of data professionals to be actively testing our systems looking for points of entry. I will be completely honest; if you aren’t you can guarantee someone else is.
Yes, I am a vendor installing an app your company purchased and we will need sysadmin rights on the box or cluster. Um. yeah you go right ahead – NOT. I hope by now, as a DBA, you have strategies in place where you will work with the vendor directly or have some form of processes that allow for tracking of such activity. Remember, these databases are yours if you maintain them; you be the gate keeper not the other way around. Don’t let anyone on your system without our knowledge and you better know what kind of data is on your system and who is accessing it.
If you aren’t careful all your eggs will be in the “protecting from the outside syndrome”. Yes potential threats are rampant from people both stateside and abroad; with that said however have you ever thought about what maybe at risk within your own walls? Do you have safeguards in place for co-workers and fellow employees? Security cannot be just thought of with outside threats. No you need to prepare for both outside and inside threats. To make it even better if you are on a DBA team is your team being audited to keep everyone honest? The data should be your top priority
These little rinky dinky passwords aren’t cutting it guys. Ensure you are following best practices and standards when setting up password strength. The easier you make it the easier it is for threats and breaches to occur. Are the passwords on your systems set to be changed every so often? But that would require a lot of work – yes and when you sign up to be a DBA or Data Professional you retain great responsibility.
Security is one place where you cannot be lackadaisical about. It is a crucial role within SQL or any platform for that matter that usually becomes an afterthought. If you are in a shop you should review your security guidelines and if you don’t have any I suggest that you take initiative and create some. Without proper security you ones business could be jeopardized and once issues arise what would become of the companies reputation; or your reputation. Be proactive, make it yours, own it, and get it done.