Editorials

Cross Database Concerns

Many DBAs modify System databases created by the data engine provider in order to host objects that are not specific to a single database. For example, I wrote a stored procedure that retrieves all running processes returning the database, SQL, and other properties of the command that was or is being executed.

For Microsoft SQL Server I came up with a few different methods to share across databases.

1) Modify the model database. Anything added to the model database is automatically added to each new database created on that instance of SQL Server. I added a sequence table nad a few table value functions to Model so that they are available

2) A second technique I like is to create a database called Shared or something like that. I place stored procedures, tables, and functions in this database that may be used with other databases. I put in this database things that are used across more than one database, but are use specific kinds of features.

3) A third technique is to use a database I call SysAdmin. This database differs from shared in that it is targeted for the needs of system administrative users. For example, I have a defragmentation process I store in my SysAdmin database. I have tables tracking history of fragmentation. It also contains stored procedures that monitor fragmentation, and then defragment indexes or updates statistics based on parameters stored in a configuration table.

I find that using Model, Shared or SysAdmin databases simplifies my disaster recovery process, because it is not necessary for me to recover my Master database.

Share your solutions for cross database techniques by leaving your comments here online, or sending an email to btaylor@sswug.org.

Cheers,

Ben