MSSQLTips.com - your daily source for SQL Server tips

Google
 
Web mssqltips.com

ESSENTIALS: Home | Tips | Search | Categories | Top 10 | Products | Authors | Blogs | Forums | Webcasts | Advertise | About
Maintaining SQL Server database metadata to identify object changes - MSSQLTips

MSSQLTips

MSSQLTips.com - your daily source for SQL Server tips
Welcome to MSSQLTips Sign in | Join | Help
in Search

Maintaining SQL Server database metadata to identify object changes

Last post 09-09-2008 10:36 AM by aprato. 2 replies.
Page 1 of 1 (3 items)
Sort Posts: Previous Next
  • 07-01-2008 12:30 AM

    Maintaining SQL Server database metadata to identify object changes

    This post is related to this tip: Maintaining SQL Server database metadata to identify object changes

    http://www.mssqltips.com/tip.asp?tip=1526

  • 09-09-2008 8:41 AM In reply to

    Re: Maintaining SQL Server database metadata to identify object changes

    To store all the database objects again in a SQL database with there definition is redundant and old school.  Use the service broker and have it write any changes in the schema of sql to a database.  This is realtime and you don't need to poll all the object every day to see what changed.  You will need to create a table for the audited changes and a stored procedure to grab the changes from the broker.  This will save you allot of resources and time.

     

    ----------------------------------------------------------------------------------------
    --  Created By: Laurence
    -- Created On: 7/1/2007
    --The statements below setup sql audting for various sql objects.  The Code sets up a services Broker with
    -- queues, Services and routes to capture certain types of SQL Objects that Change and then
    -= in turn calls a stored procedure to log the changes into a SQL server table
    --
    --
    --
    --
    -------------------------------------------------------------------------------------------------

    DROP EVENT NOTIFICATION Audit_Notify_DB_Changes ON SERVER
    DROP ROUTE NotifyRoute
    DROP SERVICE NotifyService
    DROP QUEUE NotifyQueue
    USE GbAppsAudit
    ALTER DATABASE GBAppsAudit SET ENABLE_BROKER;

    --Create a queue to receive messages.
    CREATE QUEUE NotifyQueue ;
    GO
    --Create a service on the queue that references
    --the event notifications contract.
    CREATE SERVICE NotifyService
    ON QUEUE NotifyQueue
    ([http://schemas.microsoft.com/SQL/Notifications/PostEventNotification]);
    GO
    --Create a route on the service to define the address
    --to which Service Broker sends messages for the service.
    CREATE ROUTE NotifyRoute
    WITH SERVICE_NAME = 'NotifyService',
    ADDRESS = 'LOCAL';
    GO


    CREATE EVENT NOTIFICATION Audit_Notify_DB_Changes
    ON SERVER
    FOR CREATE_DATABASE,ALTER_DATABASE,DROP_DATABASE,CREATE_INDEX,ALTER_INDEX,DROP_INDEX,CREATE_LOGIN,ALTER_LOGIN,DROP_LOGIN,CREATE_TABLE,ALTER_TABLE,DROP_TABLE,CREATE_TRIGGER,ALTER_TRIGGER,DROP_TRIGGER,CREATE_USER,ALTER_USER,DROP_USER,CREATE_VIEW,ALTER_VIEW,DROP_VIEW,CREATE_FUNCTION,ALTER_FUNCTION,DROP_FUNCTION,CREATE_PROCEDURE,ALTER_PROCEDURE,DROP_PROCEDURE

    TO SERVICE 'NotifyService', 'current database'

    ALTER QUEUE [dbo].[NotifyQueue]  
     WITH ACTIVATION (        -- Activation turned on      
      STATUS = ON,        -- The name of the proc to process messages for this queue                                    
      PROCEDURE_NAME = [dbo].[gsp_Audit_SQL_Server_Objects] ,        -- The maximum number of copies of the proc to start       
      MAX_QUEUE_READERS = 2,        -- Start the procedure as the user who created the queue.                            
    EXECUTE AS SELF                                ) ;

     

  • 09-09-2008 10:36 AM In reply to

    • aprato
    • Top 10 Contributor
    • Joined on 12-01-2007
    • Greater Boston
    • Posts 262

    Re: Maintaining SQL Server database metadata to identify object changes

     Hi

    Thanks for the alternate solution.  In my situation, it's not feasible to expect that all our customers (hundreds of them) will have SB enabled. In some cases, our customers dictate to us what they allow to be enabled and what they don't (for instance, xp_cmdshell).  The software is shipped to the customer where it is installed on their server.  It may be modified manually either by them or by a support rep after the fact.  The tables represent the structure of the database as it was shipped to the customer.  Once they get the software and install it, it's out of our hands as their DBA's (if they have one - a lot of times it's an application developer who has some basic knowledge of SQL Server) take over. Using the approach in the tip, I know I can always interrogate what's in the tables vs what's in the catalogs and know what has definitely changed. I don't have to worry if the customer has disabled Service Broker (on purpose or accidentally).

Page 1 of 1 (3 items)