Tuesday, December 31, 2013

What Matters Most Accredited Knowledge or Time Served ?

   I want to actually apologize for the layoff as well as the general vagueness of some of the posts. I guess I am more the cowboy then the surgeon after all.  I can't completely dismiss the layoff on the holidays and the continuing job search. I'll try to, but that isn't the truth.
     I have added reading and studying for some certifications to my daily routine. It has been very rewarding in more ways then one. If one is to weigh qualifications (i.e. certifications , school and such)  verse professional experience, real world experience should always win.
     I was certified quite sufficiently before having my first I.T. position. I will never dismiss certifications. Approximately ten years later, I know certifications are a glorified rubber stamp that is supposed to indicate you could build the best mousetrap or survive the burning of Rome.
     I learn every time I read. I learn from re-reading. I can attribute my ability to navigate through some of the outages I have seen in the last five or six years from that reading. However there are several things a good professional does that the certs don't test for. There are things that the good professionals do even in the heat of failing systems or unexplained application issues.
     In my first position I was given documentation for the processes I inherited. I was trained in those processes . Then as I maintained and further develop those processes, I was in charge of maintaining those processes and their documentation.
      My trainer gave me the understanding to expect a system or a process to fail. To prepare for an unexpected outcome. Simple making copies of files or knowing where to restart a failed process. Or knowing how to restore data to resume running a process.  
    If this kind of professional logic was included in your texts they might triple in size and they might finally be worth some of those price tags. I don't feel many, if any, books really teach you how to be a better all around I.T. professional. There are endless books that will teach in great detail about all kinds of amazing technologies. There are design books and other reference books.
   It is your work practices and how you apply them routinely that will best serve you when the chips are down. Be it a deadline for an application or a system failure of any nature.
  I recently experienced an individual who muscled through his I.T. career with a great deal of effort. He appeared to be a very hard worker . He spoke very confidently in his plans . So much so that he seemed knowledgeable.  I now feel like he was actually relying on a few tricks to get by and was not using best practices and textbook processes in many cases. I feel that some earlier independence and some false success led him to believe his practices were correct. It is this kind of negative experience that contradicts the previous thought that work experience trumps education in the I.T. field.
    A bad manager from my past had a very narrow definition of what "I.T. work" was supposed to mean. I didn't agree with him, but i have grown to see his point. I.T. work isn't a craftsman job.  A truly talented professional will deliver a quality product. It is not however like having sculpted for years and being able to make great pieces of art. It is like having a measurable scientific understanding of how things behave based on circumstance.      
     In short a good professional experience will always teach you more than a solid reading of the best book. The common ground is in the quality of the resource. I have had the luxury of working with quality professionals whose technical ambitions rival my own in every way. I love to read. I have chosen great texts. I am always willing to learn . I have seasoned all of this "book knowledge" with years of real hands on experience.
    I find it helpful to ask a lot of questions . I even ask questions I technically know an answer for , but I want to know my peer's insight. If your peers are patient enough, you can even play devil's advocate and bounce the different ideas off of each other. Good professionals don't have to share the same processes. They just have to be able to clinically justify why they took their approach.

Wednesday, December 4, 2013

Database Optimization : My Practices versus Best Practice

    "Best Practice" is more than a buzzword. It gets thrown around like one. You can google it but my take on best practice is its the actions that under normal circumstances will allow for best performance and disaster recovery preparedness. We should all aspire to build our environments in normal circumstances and be prepared for every possible setback that could or will eventually occur.
    When it comes to SQL Server normal circumstances can be very expensive and a lot of companies aren't on-board with these costs. We are going to try and imagine that isn't a concern . It may mean however you have to use judgement if following these practices.
      The first thing I look at is file configuration. It is my professional observation that sectioning Best practice says the system , temp, data and log files should all have separate drives. These drives should be separate from the O.S. Drive as well. If you cant have individual drives your priority should be to place the tempdb files on their own drives. The excessive writes caused by many applications create reason to isolate the I/O  requirements for these files.
      Second the data and the log files should be separated to the own drives. I believe the files should have no less than 15% unallocated space in them. So you have room on the drives for when the files fill and grow . When that occurs you should be able to manually grow the file to get the file back to an optimal unallocated percentage.
     I prefer to use multiple data files on any database over 10GB. This isnt really my rule of thumb. Its just what I have done in the past dealing with databases of all sizes. There are some thoughts about the number of files being relative to the number of C.P.U.. I do  follow this with regard to the tempdb, but I dont  follow this with database files. I factor in how many databases are on the server. I consider how which databases are more active then others. I believe the point of matching C.P.U. to file count by a ratio is to better manage the processes.    If a query needs to read data from the file it needs a C.P.U. to do some of that work.
   You may want to consider maintainability when you decide how many data files to make. It is easy to get carried away cutting a large database into many small pieces. If you need to do regular restores of a database with a great number of files it is more tedious than a database of only a few files.
   Some people might even be questioning the need to break the database into multiple files.  I take the stance that SQL Server needs how to properly identify where its data is located. If give it smaller files to find the data in you are intuitive lower the I/O needed to complete your queries.