Various reasons may cause SQL Server to get in a rut and not empty the transaction log of a database. In my case, our database backups were failing without our knowledge for several weeks, so the backups were never successful, and the transaction logs of a few databases grew so large that the backup process would still not clear out the transaction log. In one case, we had a 187MB database with a 37GB transaction log!
The insanity had to stop! A handful of databases like this would put us over the top on that particular server's hard drive storage.
The SQL Server GUI for shrinking the database rendered no effect, and even using the DBCC SHRINKFILE command was not working.
The key, as explained by Pinal Dave, is to run the SHRINKFILE command twice, with an explicit backup log truncation in between both runs. This code here will get you up and running:
SQL:
-
DBCC SHRINKFILE("MyDatabase_Log", 1)
-
BACKUP LOG MyDatabase WITH TRUNCATE_ONLY
-
DBCC SHRINKFILE("MyDatabase_Log", 1)
This freed up dozens of gigabytes on our server.
At work, someone made a request that required me to look through potentially hundreds of views in dozens of databases on our SQL Server. I certainly didn't want to examine each one at a time. How could I speed up this process with code?
Well, you can find all of your views by querying the sysobjects table, and you can retrieve the SQL behind the views by querying the syscomments table. Something like this works well:
SQL:
-
SELECT RTrim(sysobjects.name) AS ViewName,
-
RTrim(syscomments.text) AS ViewSQL
-
FROM sysobjects JOIN syscomments
-
ON syscomments.id=sysobjects.id
-
WHERE sysobjects.xtype='V' AND sysobjects.category=0
This will retrieve the SQL code and names of all the views in the current database. This simple query is the heart of the solution. But I would like to retrieve this information for all of the databases.
Well, it's easy enough to get a list of all the databases. The sysdatabases table in the master database has that list. You can query that table, perhaps filtering out some of the system or sample databases included with SQL Server:
SQL:
-
SELECT name FROM master.dbo.sysdatabases
-
WHERE name NOT IN ('tempdb','master','msdb','pubs','model')
-
ORDER BY name
Now just combine this information. To accomplish this, we'll build a stored procedure that will create a temporary table, loop through the databases and query each one for its views, insert the view information into the temporary table, and return the temporary table.
Something like this will do the trick:
SQL:
-
CREATE PROC dbo.selectViews AS
-
BEGIN
-
-
-- Vars
-
DECLARE @dbname sysname
-
-
-- Temp Table
-
CREATE TABLE #Results
-
(
-
DatabaseName varchar(200),
-
ViewName varchar(200),
-
ViewText nvarchar(4000)
-
)
-
-
-- Loop Thru the Databases.
-
DECLARE dbnames_cursor CURSOR
-
FOR
-
SELECT name FROM master.dbo.sysdatabases
-
WHERE name NOT IN ('tempdb','master','msdb','pubs','model')
-
ORDER BY name
-
OPEN dbnames_cursor
-
FETCH NEXT FROM dbnames_cursor INTO @dbname
-
WHILE (@@FETCH_STATUS <> -1)
-
BEGIN
-
IF (@@FETCH_STATUS <> -2)
-
BEGIN
-
-- Grab the Views of this Database and Put them in the Temp Table.
-
SET @dbname = RTRIM(@dbname)
-
INSERT INTO #Results
-
EXECUTE
-
(
-
'SELECT '''+@dbName+''' as DatabaseName, ' +
-
'RTrim(' + @dbname + '.dbo.sysobjects.name) as ViewName, ' +
-
'RTrim(' + @dbname + '.dbo.syscomments.text) as ViewText ' +
-
'FROM ' + @dbName + '.dbo.sysobjects join ' + @dbName + '.dbo.syscomments ' +
-
'ON ' + @dbName + '.dbo.syscomments.id=' + @dbName + '.dbo.sysobjects.id ' +
-
'WHERE ' + @dbname + '.dbo.sysobjects.xtype=''V'' and ' + @dbname + '.dbo.sysobjects.category=0 '
-
)
-
END
-
FETCH NEXT FROM dbnames_cursor INTO @dbname
-
END
-
CLOSE dbnames_cursor
-
DEALLOCATE dbnames_cursor
-
SELECT * FROM #Results order by DatabaseName, ViewName
-
DROP TABLE #Results
-
-
END
-
--
Now just execute the stored procedure and review its output.
This portion of the solution just retrieves the data. After writing this, I developed a really short and simple ColdFusion application that would output the database name, view name, and SQL to a table, and used some simple JavaScript to make it easier to search and filter the views. The client-side methods used to view and work with the data are obviously up to you.
I was updating an old app to use SQL on a new SQL Server database rather than an older Access database. As any database programmer is aware, there are irritating inconsistencies between Access SQL and SQL Server's T-SQL, such as absence of the IIF() and Trim() functions in T-SQL.
So I was going through the SQL and making these changes. I came across a very ugly IIF() function similar to this:
SQL:
-
IIF(phLead=True,'LEAD',
-
IIF(phFax=True,'FAX',
-
IIF(phVVM=True,'VVM', 'DEPT')))
Take that statement and add even more boolean fields. Clearly, the intent was to have a calculated field that had a friendly name based on which boolean field was true.
So, how can this be easily converted into a CASE statement? As it stands, CASE statements are actually more verbose than the IIF() function, and the IIF() function above is already hard to read and verbose as it is.
A direct code conversion would be something like this:
SQL:
-
CASE phLead WHEN 1 THEN 'LEAD'
-
ELSE CASE phFax WHEN 1 THEN 'FAX'
-
ELSE CASE phVVM WHEN 1 THEN 'VVM'
-
ELSE 'DEPT' END END END
Ugly, ugly, ugly. The cool thing about CASE that differs from IIF() is that you can attack it from the other direction. Instead of saying, "Is phLead true? Is phFax true? Is phVVM true?", you can instead say, "Okay, who's true? phLead? phFax? phVVM?" It sounds negligible, but the code is shorter and easier to read:
SQL:
-
CASE 1 WHEN phLead THEN 'LEAD'
-
WHEN phFax THEN 'FAX'
-
WHEN phVVM then 'VVM'
-
ELSE 'DEPT' END
Ahh, much better.
It's easy to backup or restore your database directly with SQL.
backup database MyDatabase TO DISK='c:pathtoMyDatabase.bak' with INIT
The syntax is pretty self-explanatory once you see it. Backup the database "TO DISK", or to a file at the designated path. The "WITH INIT" specifies that any existing backup file will be overwritten.
The restore syntax is nearly identical. If the database you are restoring currently exists, be sure to drop the database before doing the restore.
restore database MyDatabase FROM DISK='c:pathtoMyDatabase.bak'
Simple as that.
