February 28, 2008 at 10:45 pm
Comments posted to this topic are about the item Monitoring and Recording DDL changes on SQL 2005 (NARC)
February 29, 2008 at 2:56 am
Great example of something i have been wanting to implement for a long time.
Step 2 mentions 'attached SQL' but i cant see it, what am i doing wrong?
February 29, 2008 at 2:57 am
How can this monitor if the DBA can easily either turn it off or delete items from the output table? Seems to me that if you want a solution like this, the DBAs can't be the ones controlling what is recorded.
February 29, 2008 at 5:37 am
Where can I download the SQL code? I see it mentioned in the article, but no link to download.
February 29, 2008 at 8:33 am
There's a nice product that's using this exact technology, but already delivers everything to you with a nice GUI, easily viewable logs and all, and saves you all the hassble (also pushes changes to SourceSafe for you)
http://www.nobhillsoft.com/Randolph.aspx
thanks
February 29, 2008 at 8:47 am
What is unique about server 2005? Can't this be done with previous versions of SQL. Nice solution BTW! Presumably the new database is secured in some way eg. you are the DBO?
Peter.
February 29, 2008 at 9:06 am
yonision (2/29/2008)
There's a nice product that's using this exact technology, but already delivers everything to you with a nice GUI, easily viewable logs and all, and saves you all the hassble (also pushes changes to SourceSafe for you)http://www.nobhillsoft.com/Randolph.aspx
thanks
I see the product you mention and am sure its a worthy tool for deployment where the budget is available. I have taken the code from the article and created the objects concerned in my 'server statistics' database. I have then built two SSRS reports, based on the views created and i now have an easy to access (from anywhere on our WAN) method of seeing whats being changed on my databases. Total work time - maybe an hour in total (if i include the two posts here as well!!)
There's a place for quick and dirty solutions beside the paid-for third party tools.
thanks again for the article.
February 29, 2008 at 9:25 am
Good job! Nice to know someone has some of the same problems I do.
BTW, you might be interested in looking at this PASS demo. It has some good ideas.
The SQL 2005 DDL Audit Samples are a collection of sample applications for configuring DDL (Data Definition Language) auditing on one or more SQL Server 2005 instances. These applications were first presented at the PASS 2006 Community Summit in my presentation Building a DDL Audit Solution using SQL Server 2005. They build on top of the Service Broker and Server Event Notification infrastructure available in SQL Server 2005 to provide a means of collecting all server and database DDL events in a central database for viewing and reporting. Full source code is provided for all sample applications to allow you to better understand the technologies and easily build on or modify these samples for use in your environment.
February 29, 2008 at 11:35 am
Hi Jonathan,
Sure, there is room for ad-hoc implementation as well. I only wanted to show another option. This one's price really low (500$) does a whole lot more than what this article talks about, and actually frees you to focus on what you do best (your specific project) instead of worrying about issues like version control, which have been solved many times already.
But naturally, if you feel your ad-hoc solution answers ALL your needs, there's no need to spend more money!
Jonathan
February 29, 2008 at 1:24 pm
I like what it does and i also created 2 SSRS reports but my question is how do you make this work with users that are not sa and may not have permission to the audit db? that is the only issue i have. I love the out put it gives us and it is very scaleable.
Jim
March 3, 2008 at 8:48 am
"The attached SQL to this article contains the extended meta data for the views and is not shown in the code below."
When I scripted out the views for this article from SQL 2005 there was extended meta data with the actual view T-SQL code that I did not include with the original article. This meta data is not required for the views for the code to work.
March 3, 2008 at 8:53 am
pkenny (2/29/2008)
What is unique about server 2005? Can't this be done with previous versions of SQL. Nice solution BTW! Presumably the new database is secured in some way eg. you are the DBO?Peter.
DDL triggers is a 2005 option only. The new database is secured in a way so that only administrators (sa) would have access. Since that is usually not enough, one could put a trigger on tables that hold the information that would have a contraint that would only allow you to delete if you were logged in with your domain name.
e.g.
IF suser_sname() = 'yourdomain\username'
BEGIN
End
ELSE
ROLLBACK TRAN
END
Something like that would be fun to catch those trying to hide the audit trail.
March 3, 2008 at 8:56 am
The attached code is not required and was only meta data from the scripted 2005 SQL view.
March 3, 2008 at 11:02 am
Thanks very much for your reply!
Peter.
April 3, 2008 at 7:27 pm
This appears to be pretty much what I would want, except that I would like to be able to capture the machine name associated with the user who is making the connection. When I view the Activity Monitor in SSMS under the Management node, I can see the client computer name identified as "Host", but it is not clear how I can access that value from the trigger.
The reason this would be helpful is that there might be several people who share access to an account. Using the client computer name to distinguish where the login came from would help identify the person making those ddl changes.
Viewing 15 posts - 1 through 15 (of 26 total)
You must be logged in to reply to this topic. Login to reply