Do You Really Know What’s Running?
I’ve written before about the need to know and understand what’s happening on your server in terms of OS jobs, SQL Agent jobs and the like. Of particular interest are the recurring jobs – and their potential impact on other jobs that run later. As the day goes on, the schedules can really pile up. But, there’s one area you don’t see addressed very frequently – that’s the fact that jobs within your SQL Server Instances can really have an impact across instances on your server, and tracking this impact down can be tough. That’s where SQL Sentry Event Manager comes in. Make sure you know what’s happening, really, on your server – from the OS to SQL Server and various instances to other operations. Check out SQL Sentry Event Manager and spot the bottlenecks in a flash. Get more information here, including a whitepaper on managing SQL Server virtualization more effectively.
Video Programs/Shows available:
[Watch] Disaster Recovery and Response Planning
[Watch] SelectViews – the Accidental DBA – tips, tricks and thoughts
[Watch] SQLonCall: Manager or Leader
An Architect or Not an Architect, That is the Question
(A post from reader James)
I would like to offer some dissenting comments (I think I got the right word) in response commentator David’s comments. I’ve had some lengthy discussions with friends who were architects or architectural engineers on what they do, and I’ve spent even more time comparing the physical architectural process with computer related processes. Based on my understanding of the term architect, I think its incorrect to distinguish an architect by one that establishes standards. The definition for the word "architect" in Merriam-Webster Online is
1 : a person who designs buildings and advises in their construction or
2 : a person who designs and guides a plan or undertaking
If a person doesn’t design things, then they can’t be an architect. I happen to think it works well with IT positions – or, at least, it should. A database architect should be designing databases. Too many databases are thrown together without design.
I see the comparison with the database world looking like this: A building architect designs buildings. A database architect designs databases. (Conceptual and/or logical layer, perhaps?) A building architectural engineer ensures the building design is practical (structurally sound). A database engineer would ensure the database is practical. (Physical layer, maybe?) If the Database Administrator implements the design, then you could compare the DBA with the contractor that constructs the physical building. I realize this is not the way roles are distinguished in the database world. In fact, in a small shop like where I work, the roles are usually all filled by one person. I do think that the comparison with the physical world of architecture is very educational. Similar comparisons can be made with software engineering and system design.
I suppose a conclusion to my ramblings could be that either Database Architect or Database Engineer would be good titles, IF that is what the person is doing. Of course, that would require *some* education, even if its self-study. You really need to know what a good design is. Then there’s the issues of certification and/or licensing; but perhaps that’s only necessary if the title includes the term "Professional."
Featured White Paper(s)
BitLocker: Is It Really Secure?
What is BitLocker? How does it work? Is it a truly safe way to protect your data and applications, hard drive, and operation … (read more)
The Shortcut Guide to SQL Server Infrastructure Optimization
In The Shortcut Guide to SQL Server Infrastructure Optimization, the new eBook from Realtime Publishers, leading IT author Do… (read more)