Tattered Old Books vs. Shiny New Ones and Osmosis

I am currently moving from 1 house to another one, approximately 2 miles away. With all the packing and cleaning - uggg... I am sick of it! :) A big problem for me in the new house is limited storage space - and the number of books I have. I use books as a resource, so I have a LOT of them. In fact, when I am pursuing learning or advancing my knowledge in any area, I tend to think about books as my first resource, then online, and finally paid training classes. I have books on writing BASIC code; I even found a book that I remember my dad using to write programs on the Commodore. (Dont snicker - I know that gives away my age, but if you are only as old as you feel, I am not that old. :) )

When I was re-packing the books into a better, stronger box, ** magically **, I found something I hadnt seen in years. My old MS ACCESS book!! (dont groan too loud) This book is so worn out - the front cover is completely off even though I had taped it back on years before; soooo many pages are highlighted and written on; and it is really tattered. When I saw this book, it brought back so many good memories, and I realized, this is exactly how a technical book should look like!

I also thought about all the books I have acquired in the last year and a half. I can gauge how much learning I have wanted to do, by how many books I have. It hit me like a ton of bricks, that I havent read/used them in the same way I did that ACCESS book. I think there has been a paradigm shift in my thinking - that if I own a book, I will just somehow know all the answers that it contains. It made me realize that I really need to buckle down and read them - and actually use them in the same way as I have before. Maybe not every one of them, but enough to know that I am actually moving forward with my learning, not learning just enough to put out fires. That kind of behaviour makes it easy to trick myself into thinking I am moving forward, when in reality, I am just getting by.

My father taught me that if you get 1 idea from a book, it was worth reading (no matter how boring the rest of it was). That logic was something he really instilled in me - and something I have tried to pass on to my kids. Even though all the books I have are a pain to keep around sometimes, I wouldnt give them up for anything. I love the feel of having something tangible that I can open when I have a problem. I love knowing I can thumb through something and find what I am looking for.

One of these days I should probably leap forward into the technology age of reading books on a tablet, etc. - even my mother reads on a Kindle Fire! I am not there yet though. Somedays I feel behind the times, but other days, I just hug my books and smile.

Transformations Not Visible When You Open A Package

This isnt a "problem", its just really annoying. :) When I open some of my SSIS packages (2008 R2), I have to scroll to the left and up just to see my transformations. I put up with it for a long time, but when I got to work today (on a Monday), I was already tired and a bit upset. Then, I said "enough is enough!" and promptly tried to fix this. What I noticed for each of the packages that were like this, was the text was smaller, almost like the zoom was different than on other packages.

I looked and looked for a zoom in the menu options - but I didnt see anything. So, last but not least, I right clicked in the Control Flow open space (there are several things I access from there) and Voila! Here are the steps for fixing this:

  1. Right-click in the Control Flow open space
  2. Choose Zoom... 100 %
  3. Make a small change to a transformation (just move it a little)
  4. Save and close the package
  5. Open the package -a nd again... voila!

Its crazy how easy that was and how long I put up with it. :) Hope this makes someone's day, like mine.

For those of you who are much more of a code junkie and dont want to use the GUI, you can use the "view code" and change the "PersistedZoom" value to 100. You will also have to open the designer and move a package, then save and close in order for the change to be seen.

Doing the things I don't want to

There is a quote that I have always remembered (well sincre I read it that is).  I read it from a book talking about the AA 12 step program.  I am not, nor have I ever been an alcoholic, but the program is very successful in getting people to overcome obstacles in their life.  I was at a low point in my life and was hoping for a little motivation or inspiration, or, well... something to help get me out of my rutt.

I am paraphrasing the quote but in general it was: "I am where I am today because I did the things I didn't want to do."

I didnt know what it meant when i first read it, but there was an explanation with it too.  The author said that he didnt want to get up out of bed, he didnt want to go to  work, he didn't want to take a shower and other personal hygiene tasks.  No, instead he would rather have a drink, or would rather ________ (fill in the blank).  To me, this struck a chord and has helped me get off my lazy bum and do whatever it is that is keeping me from moving forward, in all areas of my life.

Professionally, I remember days when I was a programmer that I just didn't want to do x or y tasks.  I enjoyed what I did, but I didn't face hard challenges with enthusiasm, rather with a large sigh.  I would google my heart out and evetually after a little thinking on my part, I would come up with the solution and move on.  That was it, no fan fanfare, just glad to be done and then I moved on.

With SQL, things are different.  When I have a problem, I am anxious to find something similar to help think about a solution because I know I will learn something new.  My enthusiasm is coming back - I have even shouted "woo hoo" out loud (to the dismay of my co-workers) after solving something.  My days are very different indeed! :)

There are many times in the last year where I have been jealous that some people my age are so far along in their SQL career, and I am not. However, I know that my past experiences are helping me with a different perspective, and the people I have worked with in the past have helped me in so many ways that I didn't truly understand at the time.

With all of this, when I have to check on yet another job that failed overnight, or get up at 3 am, it isn't hard for me to snap out of it and get into the groove of happier thoughts.  I know I love what I do and the past isn't something I am ashamed of, but something to celebrate.  All because I wouldn't be where I am today if I hadnt have gone through everything I have, and done them well even though my heart wasn't truly in it.

I hope you are doing what you are truly passionate about.  It makes a HUGE difference inhow your day goes. :)

BI Maturity Model

Our IS team had a big meeting with senior management at the end of June to demo a new application that is a centralized business intelligence platform.  It showcases tiles/cards on a web page that have KPI/metrics, exceptions, tasks to be done, news, etc.  The web application was built to be a one-stop-shop for everything needed for those who work in the field.

In preparing for this meeting, I helped develop a pyramid that explains the different levels of maturity in Business Intelligence overall, and where we are.  It will help showcase what we have developed so far and show what we want to accomplish as we reach further up the pyramid.  The model came out so beautifully, I had to share it.  This was a team effort, not just me; my co-worker had a lot of specific thoughts about it, I added to it and of course, and made it pretty.

If you have any questions, please let me know.  I will be more than happy to give you my opinion of what we talked about with this.  If you want to use the picture, please make sure to link back to this post.


SQL Foundations - Day 2 2013

This post is a continuation of an earlier post that you can find here, on Day 1 of the SQL Foundations course I attended.  The session was presented by: Allan Hirt (blog | twitter), and Ben Debow (blog | twitter) .


Day 2: Thursday, August 29th

Session 4: Indexing Fundamentals

Ben was the sole presenter on this topic. He gave many ideas to think about as well as explaining about indexing. Indexing is more than just putting an index on a table, it requires more planning. Creating an overall indexing strategy will help find that balance between SQL, performance and hardware that is the true desired goal. To start off with, focus on the highly reference objects first. Ben gave a demo which showed a great tool to use, SQL Sentry Plan Explorer, to help dive into more depth. He also showed how Excel can be used to filter and sort the index usage statistics to gain much more insight into what to tackle, and when.

He also gave multiple tips, including making sure to know when the SQL server instance has been restarted. All of the metadata which is helpful to review is cleared out when the instance is restarted.


Session 5: Administration Essentials

I was really looking forward to this session, and was not disappointed! Both Ben and Allan started this session with a pie chart that showed all the high level tasks a DBA is responsible for: Backups/Restores; Monitoring; Security and Auditing; Performance; Maintenance; Inventory and configuration. For each of these topics, they explained many things that are useful to watch out for and the tools to use to do so, also metrics/thresholds to use as guidelines. I took a LOT of notes in this session and was pleasantly surprised to learn specific things I can utilize right now.

At the end of the session, they made sure to mention that all the tools in the world are great, but dont forget about YOU. Keeping up with your training and learning is important as well. You can use classes, webcasts, local user groups, conferences, brown bag learning lunches, etc., to stay current. You never know when that knowledge will be handy!


Session 6: Troubleshooting 101

As with Tuesday, I was pulled away from this session by work (ohh gotta love it - huh?). I did get to listen to the first few minutes though. They started with some sage advice: Listen fully to the problem first, dont just start clicking half way through what the person talking is saying. Also, develop and use a formalized troubleshooting approach to increase effectiveness, this will help in times of emergency when someone is literally watching over your shoulder.

I will watch the recorded version of the session at a later time and finish this update.

SQL Foundations - Day 1 2013

The entire SQL Foundations course is geared towards people who are new to SQL Server or who needed a refresher.  The course consists of 6 sessions, each about an hour long, over a 2 day period.  Over the course of 2 blog posts, I will be giving a very brief summary of each session.  If they sound interesting to you, you can make sure to follow either of the authors, Allan Hirt (blog | twitter), or Ben Debow (blog | twitter) to learn when the next offering will be.  I have made a new post for Day 2, which can be found here.


Day 1: Tuesday, August 27th

Overall, I am glad I attended this first day's sessions.  I appreciate the fact that both presenters have a way of connecting with their audience and explained the concepts in an easy to understand format.


Session 1: Hardware, Infrastructure, and Operating System Concepts for the DBA

This was a great session - both Allan and Ben discussed multiple topics, such as, Hyper-threading, Memory, Networking, Supportability, Security in general, Standardizing deployments, and the importance of Testing.

Overall, this session seemed to explain the importance of how knowing the hardware and technology that SQL Server sits on, will help a DBA immensely.  Sometimes an issue can appear as though it is within SQL Server, when really it is due to underlying factors.

Allan finalized the session talking about the importance of testing.  A lot of mistakes can be avoided by testing before making a change in production.  Whether it is as big as an upgrade, or a normal patch, or a simple configuration change, testing the change allows you to see what issues may arise.


Session 2: Virtualization and the Cloud for DBAs

This session talked about the cloud and about virtualization technology in general.  Again, both Ben and Allan talked about the terminology that is used when thinking or working in the Cloud.  It was refreshing to not have to know what the acronyms meant - they were explained beforehand (halleluiah!).  The session talked about what success looks like for the private or public cloud.  It also gave key concepts to think about, such as possible limitations and it's overall level of maturity.

The summary included a note that when Microsoft has a change, it is pushed to the cloud first.  That reality may give a big clue about how permanent Microsoft views the cloud.  It seems to be that the cloud is something to learn about so that when you do encounter it - you are prepared!


Session 3: SQL Server High Availability

As it goes, I was taking the sessions in the middle of a work day.  I had an emergency that I had to look into, and didn't get to catch most of this session.  I know that Allan was the sole presenter, he started out mentioning that this was a topic "near to his heart."  By catching bits and pieces, I know he explained what the difference was between High Availability and Disaster Recovery.  He also talked about what it would take to deliver an aggressive level of uptime.  I know he performed demonstrations during the presentation, and I wished I had been able to participate.  I am hoping the recorded session will be made available at a later time.  If so, I will expand upon this brief summary.


TSQL Tuesdays # 45

It is time for another TSQL Tuesday - Mickey Stuewe (blog | twitter) is hosting this month and the topic is "Invitation–Follow the Yellow Brick Road". Well, here it goes..

I worked for a medical device company that needed to audit quite a bit of data. I was lucky enough to work with some wonderful and talented people. One of those persons was the DBA. I took what he did and said as database gospel. He was the type of person who would help you understand things if you asked - and if he didn't know he would tell you, but get back to you later with an answer. He probably got sick of seeing me as often as he did. :) When I started at that company, I knew that I had enough understanding to be dangerous, but I also knew full well and good that I had a LOT to learn. I took the opportunity to learn from him.

He set up a system of auditing using triggers on MANY tables in the transactional database. I started learning everything I could about using the different types of triggers (insert, update, delete) and the way to use the system tables to put the data here and there, and to record what happened and by whom. I ended up learning a lot of "magic behind the curtain" about SQL and triggers along the way.  When I was hired, the database used was SQL 2000 (we later went through a couple of upgrades - the validation was a lot of work). I never even thought about other options for auditing - this solution worked well, why wouldn't everyone use it. :)

When I started at my current job, I realized my passion for SQL. I knew I liked it before, but this job has really given me an opportunity to get my hands dirty much more. That is when I was introduced to the ETL and the data warehouse. I had been introduced to the concept of a warehouse before, so that wasn't new, but I hadn't been involved in the manipulations and loading of data.

In doing research about ETL in general, I learned about Change Data Capture (CDC) and Change Tracking. I have to admit, I was initially a little bummed. I had learned something that was working very well, but here was this new functionality that had the same end result, just worked differently. I eventually learned quite a bit more about it and was thrilled with the possibilities. I wanted to start using CDC with the ETL to help with incremental loading. I haven't gotten my chance and might not be able to since we are phasing out the only data source that we house internally - all other data comes from outside vendors by either files or database backups. Therefore, I put the thought of auditing on the back burner.

Recently, however, we had a need on the application development side, to audit who made certain changes. BINGO - perfect timing - I had already done the research previously, so I knew how to implement things to get what we needed up and running pretty quickly. Of course, as everything else, other priorities have slipped in, but I am almost done with the implementation. Setting up the CDC portion was a snap, getting the data where I want it so I can use it is what is taking more time. I am taking the audited records and putting the changes into an XML string then saving that in a central repository for audit logging and reporting (but yet keeping it dynamic so I can have 1 script no matter what the data structure of the audited table looks like).

In summary, I learned a lot from looking into what made the first auditing process I was exposed to "tick". Then, I learned more about changes in functionality between SQL 2000 and SQL 2008 R2.

I didn't know about the SQL community until a year ago (Thank you - SQL Saturday in Baton Rouge 2012). I have met some wonderful people so far and look forward to meeting even more! All in all, it is really awesome to say that while I don't have the "admin" type of historical knowledge a lot of people do, the auditing topic is something where I can say I understand the before and after.

Thank you Mickey for such a great topic - and talk to you soon!

Thank you for visiting!