Friday, May 30, 2008
No more wasting time updating your many bosses with the results of whatever ad-hoc queries they keep asking you to run for them, no more IT meetings to decide whether you need to take the time to implement a report that you think you will be asked to generate again and again. With RSS Reporter you write your query once and you send your bosses the link to the automatically generated RSS feed and they can get an update anytime they want, on whatever device they want without having to bug you ever again for that same query.
Is this cool tool expensive you ask? How does free sound to you? Yes, it is completely free for one SQL Server instance and only $99 for 5 SQL Server instances.
You can read more about it and download your free copy from: http://www.xsql.com/download/rss_reporter/
Wednesday, May 28, 2008
So, what is a DBA to do? Well, fortunately the solution is very simple – it is called RSS Reporter for SQL Server (http://www.xsql.com/products/rss_reporter/) - it is free for one SQL Server instance and extremely affordable for more instances. You simply add each server you need to monitor into the RSS Reporter workspace, set the options to filter only the jobs and conditions you want and the RSS Reporter automatically generates an aggregate feed that gives you a complete view of all the jobs from all the servers and even better, it allows you to drill down on each job and view the details. You can subscribe to and read the feed from any device without having to worry that the alerts are not coming. You go on vacation – no worries – someone else can easily monitor the job status feed – nothing to setup or configure, the other user simply subscribes to the same feed you get. Now that’s beautiful!
Check it out for yourself and spread the word to the community – let’s not keep it a secret anymore.
Thursday, May 22, 2008
Before we get to "what sets xSQL Profiler apart" we need to first explain what it does so here is the brief list of what it allows you to do:
- register SQL Server instances and databases in the xSQL Profiler workspace;
- define highly granular events that you may want to trace (a predefined set comes with the product);
- define traces (choose the servers / databases you wish to trace; choose the events; set filters so that you can trace exactly what you want nothing more, nothing less);
- schedule traces - you can define as many start/stop intervals as you wish and set those intervals to occur only once or recur daily, weekly, monthly;
- view trace data using the xSQL Profiler predefined viewing panel that allows you to filter sort and group the events;
- query the central repository directly using T-SQL.
Now, how is this different from the rest of the tools out there:
- you can deploy this monitoring and auditing platform in minutes days, weeks or months - there are no agents on the servers that will be traced - you simply install the xSQL Profiler on a workstation or server where the xSQL Profiler service will also be running and you are done with the installation.
- allows a high level of granularity in defining events / traces thus eliminating the unnecessary load placed on servers when you trace more than you need to.
- It is so simple even a "cave man could do it" - these geico commercials are getting to me :)
- IT IS ABSOLUTELY FREE (only for up to two SQL Server instances that is - what did you think, someone's got to pay for all that work we have done) <- -="" any="" couldn="" fine="" finer="" here="" i="" it="" li="" make="" print="" read="" t="" than="" the="" this="">->
Tuesday, May 20, 2008
Now, at this point, this is not a moral dilemma for us yet as we have a long way to go to get to the position where we may have enough power to get to such exclusive advertising deals - of course not with google but with small user group sites etc., but we have more than once experienced knocking on some doors and getting turned down with a "sorry, we can't advertise your products as they compete with the products of one of our special sponsors". Of course that does not feel good... but when reason overpowers those bad feelings we find ourselves asking the question "wouldn’t we do the same thing if we could?".
So the question to all of you is: if you had the power would you do it or not, and why yes or no?
Thanks for your comments!
Friday, May 16, 2008
The user can choose to wrap all the scripts in one big transaction, wrap them in separate transactions or execute them without wrapping them in transactions.
So how is xSQL Script Executor helpful for database administrators? Well, here is a simple scenario:
- you are the database administrator in charge of executing the scripts that individual developers and dbas from different units in your organization place in a repository daily.
- Each unit has its own “folder” where its developers and dbas place their scripts.
- Every night you are faced with this simple but daunting task – execute those scripts against one or multiple databases. What are your options:
o Manually open those scripts one after the other and execute them and hope to be done by next morning; OR
o Get xSQL Script Executor, spend a few minutes creating the list of folders/scripts to be executed, order them, automatically generate command line commands – one for each server/database the scripts need to be executed against, put those in a batch file, schedule the batch to run when you want it to run and you are done. There, that part of your job has been converted from many boring hours into… well, whatever you want it to be – you can still pretend you are busy running those scripts though.
Don’t forget to do your friends a favor – tell them about this life saving (well for some it is) tool – here is the link again: http://www.xsql.com/products/script_executor/.
Wednesday, May 14, 2008
Project x is in jeopardy! While you may have been led to believe that the project is near completion that is as far from the truth as it can get, not only is the project nowhere near completion but if things continue the way they are it will never be complete…”
I can only guess that hundreds of commanders on the ground in Iraq have in their mind probably written a similar letter addressed to the Commander In Chief when he declared “Mission Accomplished” at a time when the mission had just started. Tenths of engineers and workers at Boeing subcontractors have probably done the same as Boeing suffered one embarrassing delay after the other on its Dreamliner.
At one capacity or another we have all, especially those of us in the IT field, likely been actors in similar “plays” at some point in our careers and we know how those usually unfold. The question I wish to discuss is: what are the factors that create the conditions for such “doomed from the start” projects and how can an organization reduce or eliminate the likelihood of such conditions forming?
Before we get to the answer of that question let’s clarify something that has the potential to confuse the analysis / discussion. There are “do or die times” when a critical business need dictates what would normally be considered unrealistic deadline – in such cases everyone from the very top to the very bottom is aware of the situation – if the people involved are able to pull it off they will be considered, deservedly so, heroes – if they fail everyone understands. Such scenario is not subject of this article – what I wish to analyze and discuss here is unreasonably tight deadlines that are not unequivocally dictated by a true business need but are brought about by other factors.
Here are what I believe to be some of the main contributing factors:
- ignorant management that has no idea of the effort required coupled with an autocratic style (one may argue that ignorance of management often leads to autocracy);
- lack of trust on the commitment of the team coupled with lack of productivity measuring tools and techniques;
- overambitious and cowardly managers trying to please their bosses at any cost;
- failure of the management to recognize that team members are humans and have lives beyond work;
- insecure team members choosing to deal with failure later rather than facing the management now;
- inexperienced team ready to “bite” any size project oblivious of its “chewing” capability;
An occasional project failure may be an indication that one or more of those factors came into play when that project was defined and approved but the organizations self-correcting mechanisms that are derived from that organization’s culture are working properly. A frequent occurrence of project failure on the other hand would be an indication of a much deeper problem related to the culture of the organization in question which is hard to change.
How can an organization cultivate the right culture – the one that produces success rather than failure?
There are two ways to cultivate a certain culture amongst a social grouping:
- the “bible way” – that is, if you do or don’t do something you are going to hell / heaven; In this case the motivation of the individuals to do or not do something is their natural desire to secure a better future for their next life.
- The “reason way” – that is if you do or don’t do something those are the direct consequences and this is how those consequences ultimately affect you. As a reasoning being you are of course expected to choose to do / not do what benefits you the most or hurts you the least in this life.
For the purpose of this discussion I would classify the “if you do/don’t do this you will be fired” under the “bible way”.
While the “bible way” has been extremely effective in cultivating a culture where stealing, cheating, hurting others etc. are unacceptable I believe that it wouldn’t be very effective in cultivating the right culture in an organization. An organization must rely on the “reason way”. You could put a big banner in the main entrance of your headquarters building stating: “Autocracy is not the remedy for ignorance, education is!” but is that going to create a culture where autocracy is not acceptable – no, it is not going to accomplish anything. A long and persistent educational campaign dissecting the autocratic style and identifying the advantages and disadvantages of it and how it affects all involved is needed.
The same is true for any and all aspects of an organizations culture – slogans don’t produce culture, reason does.
This just scratches the surface of this deep and very interesting subject but it makes the point I wanted to make, namely that when a project fails the organizations culture should be scrutinized and furthermore it should be recognized that adjusting the organization’s culture can not be mandated – it can only be accomplished through a long and persistent educational process.
Feel free to leave your comments here – I can’t promise to respond but I will definitely read them all.
Thursday, May 1, 2008
Another thought flashes through your mind – how could Query Analyzer/Enterprise Manager / SSMS do this – shouldn’t I get a warning of the type "hey you are trying to update this table but I don't see a where clause. Are you sure you want to do it?"? Sure, you can blame the tool for your stupidity but that’s not going to help – the tool is just that, a tool and if it does what you tell it to do then it is really doing its job.
Then, you start beating yourself up: "why o why didn't I wrap this in a transaction" - after seeing that all rows were affected I could have simply rolled back and no harm would have been done. Well, you deserve the beating!
Are you completely doomed? Not necessarily, it is not time to run yet so pull yourself together and think this through. First if the table/columns you updated contain data of critical importance it is likely that those columns are being audited – so you can look for that audit table and use that to clean up the mess you just made. If no such thing is available then your next and likely last lifeline is the backup – restore the most recent full backup as a new database, apply the subsequent differential backups and the logs up to the last log backup before you made the mess - after you do that you can safely repair most of the damage. If for whatever reason you don’t have a backup either then you are officially doomed – just run for cover.
I emphasized here the most extreme case, that of a completely missing where clause but this applies equally to the more likely case of an incorrect “where clause” that filters the wrong set of rows. The difference is the scope (the number of rows affected) and the fact that while it is very likely that you will immediately realize what you did in the case of the missing where clause in the case of an incorrect where clause you may not even realize that you messed up until a future event uncovers the mess.
So, what’s the lesson here:
- if at all possible do not run ad-hoc update queries on a production database; A production database should only be updated through thoroughly tested interfaces that implement proper checking and warning mechanisms to avoid un-intentional changes to the database.
- if you must (that should be rare) then:
o make a copy of what you are about to change – if you have to reverse the changes this copy will save you a lot of time and frustration;
o always wrap your statement /script on a transaction and before you commit the transaction make sure to verify the number of rows being affected. You may also want to spot check some of the rows that were updated to ensure that what happened is what you intended to happen.
o Insert detailed comments/explanation in the query/script you executed including the server and database against which you executed it and the exact data and time you executed it and save it.
- Always keep in mind that updating a production database is no joking matter so be safe, don’t take shortcuts!