About Me

I thought I'd share some of my background information for those of you that read my blog articles and newsgroup posts.   I hope that this will provide some insight into why I'm motivated to contribute a significant amount of my personal time to helping out my peers in the SQL Server community.  

Why I'm Passionate About SQL Server

I’m very proud of the fact that our firm has the fastest web response time of any brokerage firm and attribute much of this to our intelligent use of Microsoft SQL Server.   Securities trading is one of the most demanding of all OLTP database applications and performance is absolutely critical to the success of our customers.   Not only does this demonstrate that SQL Server can handle our peak transaction loads during the heavy market open period, our actual performance is not unlike the TCP-E OLTP benchmark results posted for Microsoft SQL Server on similar hardware.   I think our experience validates that the TPC-E OLTP benchmark is an accurate measure of the performance one might expect with real-world database applications and that Microsoft SQL Server is up to this demanding challenge.  

We are not alone in the securities industry in using SQL Server for mission-critical high-performance trading applications.   Every trade placed on the NASDAQ exchange goes through their SQL Server market dissemination system.  

My Background: Mainframe

I began my career when even “mini” computers filled a good-sized room.   I started out as a Business Administration major but changed focus when I took Introduction to Data Processing.   I instinctively realized the great utility of computers so I took all the programming courses I could, including COBOL, RPG, Assembly, and BASIC.

I got a computer operator job while I continued by studies.   I recall when it took an entire weekend for technicians to upgrade the IBM mainframe memory to 16MB RAM (sic).   The cost of that upgrade would probably buy several new automobiles today.

My first programming job involved developing and maintaining batch programs and reports on a venerable IBM 360 mainframe.   I’m sure many trees were killed to meet demand for the punched cards I used to create COBOL programs.   Structured programming (limited GOTOs, one entry point/exit per routine) was the latest programming technique.   I moved on to programming IBM 370 batch and CICS (online) applications with a little HP 3000 series programming thrown in to keep things interesting.   The mainframe applications used TOTAL as the back-end database at the time along with VSAM files.

Even though I enjoyed programming, I was ready for a new challenge and took an opportunity to move into mainframe database/storage administration area in 1983.   My new role offered me an opportunity to learn the intricacies of database backup/recovery.   I remember when several disk drives we had recently installed began to crash a few months after commissioning.   So many went bad that I became quite proficient at disk drive initialization, full volume restores, database file restores and forward recovery.   I didn’t care much for the 24x7 on-call and long hours but the hands-on disaster recovery experience was invaluable.

We later migrated our mainframe databases from TOTAL to TIS (the next generation of the product from Cincom, Inc.) and then later to ADABAS (Software AG).   Although these DBMS systems weren’t relational from the engine perspective, I still followed normalized database design practices and occaisionally bent the rules when appropriate.   Some of the databases were very large so I paid close attention to the performance aspects of indexing, reorganization and file placement.   I kept source copies of all database DDL and followed sound configuration management practices.

On to SQL Server

I first got involved with SQL Server when version 4.21a was released on Windows NT 3.1 Advanced Server (we also had some SQL Server on OS/2 and I was fortunate enough to dodge that bullet).   I had about 10 years of mainframe DBA experience by then but knew little about SQL Server.   Application developers rather than DBAs were primarily responsible for our SQL Server boxes in our shop at that time.   Although we only had a couple of SQL Server database servers, these were used as the back end for some of our more visible clients.   Management realized that more DBA involvement was needed so I was tasked with implementing SQL Server backup/recovery.

I took a SQL Server Administration course and assumed DBA responsibility for a server hosting an important client.   I was an expert mainframe DBA but wasn’t yet comfortable in the Intel server world.   However, I soon got an opportunity to exercise my new knowledge when a developer got tempdb stuck in RAM on one of the other production SQL boxes and couldn’t to move it back to disk.   I was able to save the day by suggesting some sp_diskdefault magic.   This incident gave me confidence and I went on to excel as a SQL Server DBA.   I transitioned to a primarily SQL Server DBA over the next couple of years.

I joined a telecom software company as a SQL Server developer during the dot-com boom.   The pace was crazy but the work was quite interesting.   The position evolved into a Database Architect and I enjoyed the challenges involved in designing databases with billions of rows and processing raw CDR records (call-detail records generated by telecom switches) at a rate of many millions per hour while providing sub-second end-user response time.   We had a strong development team and I really enjoyed working closely with application developers and architects.   I was also lucky enough to get tasked with programming .NET Windows services and applications for the middle tier, which provided the opportunity to learn a lot about OOP and .NET data access.   I’ll always be a programmer at heart even though I focus on the database side.

When I moved on to my current position at an on-line brokerage firm in 2006, I had to choose between a DBA or database developer role.   The choice was difficult because I like both worlds.   I decided on the development path mostly because of my preoccupation with performance; I've learned that application design, database design, query and index tuning accounts for the lion's share (at least 80%) of performance.   As part of the application development team, I can help ensure the application and database work in concert to maximize performance, concurrency, and scalability while providing the best possible end-user experience.  

In the community

I first started participating in the SQL Server newsgroups back in 1996.   I would ask an occasional question but, more importantly, I was able to glean quite a bit of knowledge simply by reading the Q&A.   I appreciated the willingness of individuals to share their time and expertise to help others.   Over time, I found myself answering more and more questions.   Microsoft acknowledged my contributions to the on-line community with a MVP (Most Valuable Professional) award in 2000.

I particularly like the online community because of the peer review of my answers to user questions.   Although I get it right more often than not, it's nice to know that there are many knowledgeable individuals with diverse experience willing to provide alternative solutions or corrections.   There is often many ways to solve a problem, with each solution having its own merit.

Mentoring has always been a great reward to me.   I enjoy sharing my passion for SQL Server along with my knowledge.   My philosophy is that it is better to teach a hungry man to fish than to give him a fish.   I believe it is more than coincidence that a number of the folks I've worked with have gone on to successful careers at Microsoft.  

I also enjoy participating in our local St. Louis SQL Server User Group where I regularly present topics and participate in Q&A.   I like networking with the other SQL Server pros in the area, who work in environments ranging from large Fortune 100 companies to single-person IT shops.   The group is quite active and growing thanks mostly to the hard work of the other officers.   I'm most thankful for their community support.   The SQL Server community is all about people helping each other.   I strongly encourage other SQL Server professionals to share their expertise in the newsgroups, online forums and local user groups.


Dan Guzman
Microsoft SQL Server MVP