Then run a job every minute or so to query the stage table, run some BCP commands to extract the data in a CSV format.

TRIGGER

CREATE TRIGGER Trigger on TEST_TABLE
after insert
as
IF EXISTS (SELECT * from TEST_TABLE as c JOIN inserted AS I ON c.column = i.column where i.columnb = ‘Condition’)
BEGIN
INSERT INTO stage(column1, column2, column3) SELECT column1, column2, column3 from inserted
END
GO

Export Call

declare @cmd varchar(2000)
select @cmd = ‘bcp “select * from stage” queryout c:\audit_’+convert(varchar(8),getdate(),112)+’_'+Replace(CONVERT(CHAR(8),(CONVERT(DATETIME,CURRENT_TIMESTAMP,113)),114), ‘:’, ”)+’.csv -t, -T -c’
EXEC xp_cmdshell @cmd
GO
delete from stage

The Replace(CONVERT(CHAR(8),(CONVERT(DATETIME,CURRENT_TIMESTAMP,113)),114), ‘:’, ”) gives me miltary time…like that a lot. I will store that for later use.

Anyway, this works pretty well in testing. May need to make some tweaks before going live. I first tried running the BCP in the trigger itself, but had the trigger freeze problem that others reported and read some articles about how this is probably not the best idea. This way is not as realtime, but works well for what I need.

/* CREATE A NEW ROLE */
CREATE ROLE db_executor

/* GRANT EXECUTE TO THE ROLE */
GRANT EXECUTE TO db_executor

USE [database name]
GO
exec sp_MSForEachtable @command1=”ALTER INDEX ALL ON ? REBUILD”
GO
exec sp_MSForEachtable @command1=”UPDATE STATISTICS ? WITH FULLSCAN”
GO

I started to receive this error message:

ALTER INDEX failed because the following SET options have incorrect settings: ‘QUOTED_IDENTIFIER’. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or query notifications and/or xml data type methods. [SQLSTATE 42000]

When you try to rebuild a indexed view or a computed column you will run into this error. I quickly tried adding a SET QUOTED_IDENTIFIER ON to the top of my query but after some reading found out that this has no impact when using the sp_MSForEachTable.

For now I created a DB Maintenance Plan to rebuild the indexes and recompute the statistics. Another way around the issue would be to build a custom script/stored procedure to loop through all the tables in sys.objects (where type = ‘U’ and then using the SET statement before each ALTER INDEX statement.

USE [database name]
GO
exec sp_MSForEachtable @command1=”ALTER INDEX ALL ON ? REBUILD”
GO
exec sp_MSForEachtable @command1=”UPDATE STATISTICS ? WITH FULLSCAN”
GO

Background:
We had to rename our production server after software upgrade this weekend. We did not want anyone hitting the old server. The problem started.

Solution:

1. Run a select @@SERVERNAME. Verify that you have the correct server name. The server name was incorrect due to the server rename so I had to run the following commands:
sp_dropserver ‘Old Server Name’

sp_addserver ‘New Server Name’

You then have to restart the SQL Service. Once you restart run the select @@SERVERNAME command again and verify the name is correct.

2. Select * from msdb..sysjobs. This will show you the Originating Server Column. In my case this was the original server name.

3. Run an update statement to fix the server name: update sysjobs set originating_server = ‘New Server Name’ where originating_server = ‘Old Server Name’

After that final update statement I was then able to update/edit/delete the jobs.

That blackout portion is my database name. The script is a simple script to query a database and dump some data into a .csv. Well the error started driving me crazy. The code looked correct. I kept pouring over the code again and again looking for an answer.

Did some google searches and did not find a whole lot of information. Finally the answer hit me. While running the script I kept opening it up in a text editor. The resulting CSV is really wide and my header column data is longer than the data in the rows. So one time I opened the CSV in Excel to see the data lined up a little better.

Well I forgot to close the CSV in Excel before running the script again. The error message threw me off. Instead of saying something like access denied or permission denied, it gives me some wild context changed error.

Oh well, I closed down Excel and badda-bing.

1. Set the SQL Server Server service to start as a domain account that has appropriate permissions (Read/Write) to your UNC path
2. Run the setspn tool to register your domain user servicePrincipalName field in AD. You can use ADSIEDIT.msc console to check the status of the command. setspn MSSQLSvc/ServerName.domain.com Domain\User [see my Epic quest article for more details]
3. Create the SQL backup job to backup the database to the UNC path: BACKUP DATABASE [dbname] TO  DISK = N’\\servername\share_name\filename.bak’ WITH  INIT ,  NOUNLOAD ,  NAME = N’backup name’,  NOSKIP ,  STATS = 10,  NOFORMAT
4. Celebrate a job well done, perhaps with a Mt. Dew or your choice of work approved beverage.

From Books Online:
“A deadlock occurs when two or more tasks permanently block each other by each task having a lock on a resource which the other tasks are trying to lock. The SQL Server Database Engine automatically detects deadlock cycles within SQL Server…The Database Engine chooses one of the sessions as a deadlock victim and the current transaction is terminated with an error to break the deadlock.”

Man I am only a paragraph in and I am sleepy. Must be because it is Monday. Anyway I went ahead and fired up some trace flags on my instance:

DBCC TRACEON (1204,1205,3605, -1)
GO
DBCC TRACESTATUS(-1)
GO

• Trace 1204 reports deadlock information formatted by each node involved in the deadlock.
• Trace 1222 formats deadlock information, first by process and then by resources.
• Trace 1205 returns more detailed information about he command being executed at the time of the deadlock. This flag is now undocumented.
• Trace 3605 sends trace output to the error log.

You can set these trace events as start up parameters if you desire, however you will need to bounce the service to make it happen.

After I turned on the traces listed above, I fired up a SQL Server Profiler and started a profile using these Events: Deadlock Graph, Lock:Deadlock, and Lock:Deadlock Chain.

And now we wait….and wait…Wondering if a deadlock will happen. My next step is to setup my deadlock profiler trace as a server side trace so I do not have to leave profiler up and running.

UPDATE: Converted the profiler trace into a server side trace. Just hop into profiler, configure your trace, start the trace, stop the trace. Then use the Export/Script Trace Definition…under the file menu. This will generate a .SQL script to execute to fire up the trace. You will need to insert a trace file path and name. Then once you execute the script the server side trace will start.

Example of the trace definition for the above Deadlock trace:

/****************************************************/
/* Created by: SQL Server Profiler 2005             */
/* Date: 04/26/2010  08:19:16 AM         */
/****************************************************/

– Create a Queue
declare @rc int
declare @TraceID int
declare @maxfilesize bigint
set @maxfilesize = 5

– Please replace the text InsertFileNameHere, with an appropriate
– filename prefixed by a path, e.g., c:\MyFolder\MyTrace. The .trc extension
– will be appended to the filename automatically. If you are writing from
– remote server to local drive, please use UNC path and make sure server has
– write access to your network share

exec @rc = sp_trace_create @TraceID output, 0, N’e:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\Deadlock_Trace.trc’, @maxfilesize, NULL
if (@rc != 0) goto error

– Client side File and Table cannot be scripted

– Set the events
declare @on bit
set @on = 1
exec sp_trace_setevent @TraceID, 148, 11, @on
exec sp_trace_setevent @TraceID, 148, 51, @on
exec sp_trace_setevent @TraceID, 148, 4, @on
exec sp_trace_setevent @TraceID, 148, 12, @on
exec sp_trace_setevent @TraceID, 148, 14, @on
exec sp_trace_setevent @TraceID, 148, 26, @on
exec sp_trace_setevent @TraceID, 148, 60, @on
exec sp_trace_setevent @TraceID, 148, 64, @on
exec sp_trace_setevent @TraceID, 148, 1, @on
exec sp_trace_setevent @TraceID, 148, 41, @on
exec sp_trace_setevent @TraceID, 25, 7, @on
exec sp_trace_setevent @TraceID, 25, 15, @on
exec sp_trace_setevent @TraceID, 25, 55, @on
exec sp_trace_setevent @TraceID, 25, 8, @on
exec sp_trace_setevent @TraceID, 25, 32, @on
exec sp_trace_setevent @TraceID, 25, 56, @on
exec sp_trace_setevent @TraceID, 25, 64, @on
exec sp_trace_setevent @TraceID, 25, 1, @on
exec sp_trace_setevent @TraceID, 25, 9, @on
exec sp_trace_setevent @TraceID, 25, 25, @on
exec sp_trace_setevent @TraceID, 25, 41, @on
exec sp_trace_setevent @TraceID, 25, 49, @on
exec sp_trace_setevent @TraceID, 25, 57, @on
exec sp_trace_setevent @TraceID, 25, 2, @on
exec sp_trace_setevent @TraceID, 25, 10, @on
exec sp_trace_setevent @TraceID, 25, 26, @on
exec sp_trace_setevent @TraceID, 25, 58, @on
exec sp_trace_setevent @TraceID, 25, 3, @on
exec sp_trace_setevent @TraceID, 25, 11, @on
exec sp_trace_setevent @TraceID, 25, 35, @on
exec sp_trace_setevent @TraceID, 25, 51, @on
exec sp_trace_setevent @TraceID, 25, 4, @on
exec sp_trace_setevent @TraceID, 25, 12, @on
exec sp_trace_setevent @TraceID, 25, 52, @on
exec sp_trace_setevent @TraceID, 25, 60, @on
exec sp_trace_setevent @TraceID, 25, 13, @on
exec sp_trace_setevent @TraceID, 25, 6, @on
exec sp_trace_setevent @TraceID, 25, 14, @on
exec sp_trace_setevent @TraceID, 25, 22, @on
exec sp_trace_setevent @TraceID, 59, 55, @on
exec sp_trace_setevent @TraceID, 59, 32, @on
exec sp_trace_setevent @TraceID, 59, 56, @on
exec sp_trace_setevent @TraceID, 59, 64, @on
exec sp_trace_setevent @TraceID, 59, 1, @on
exec sp_trace_setevent @TraceID, 59, 21, @on
exec sp_trace_setevent @TraceID, 59, 25, @on
exec sp_trace_setevent @TraceID, 59, 41, @on
exec sp_trace_setevent @TraceID, 59, 49, @on
exec sp_trace_setevent @TraceID, 59, 57, @on
exec sp_trace_setevent @TraceID, 59, 2, @on
exec sp_trace_setevent @TraceID, 59, 14, @on
exec sp_trace_setevent @TraceID, 59, 22, @on
exec sp_trace_setevent @TraceID, 59, 26, @on
exec sp_trace_setevent @TraceID, 59, 58, @on
exec sp_trace_setevent @TraceID, 59, 3, @on
exec sp_trace_setevent @TraceID, 59, 35, @on
exec sp_trace_setevent @TraceID, 59, 51, @on
exec sp_trace_setevent @TraceID, 59, 4, @on
exec sp_trace_setevent @TraceID, 59, 12, @on
exec sp_trace_setevent @TraceID, 59, 52, @on
exec sp_trace_setevent @TraceID, 59, 60, @on

– Set the Filters
declare @intfilter int
declare @bigintfilter bigint

– Set the trace status to start
exec sp_trace_setstatus @TraceID, 1

– display trace id for future references
select TraceID=@TraceID
goto finish

error:
select ErrorCode=@rc

finish:
go

]]> http://justsql.wordpress.com/2010/04/26/sql-server-deadlock/feed/ 0 thejoestory http://justsql.wordpress.com/2010/03/25/import-multiple-xml-files-into-access/ http://justsql.wordpress.com/2010/03/25/import-multiple-xml-files-into-access/#comments Thu, 25 Mar 2010 18:11:55 +0000 thejoestory http://justsql.wordpress.com/?p=162 ]]> So boss emails me and asks hey can you import 2,900 XML files into this attached Access database. Of course I say sure thing, no sweat. I knew this I was not the first person in the world with the need to import XML files into access so was confident I could find something on Google to facilitate.

The first thought I had was just throwing the data in a SQL Server database (boss mentioned SQL Server is a fine destination also) using an SSIS pacakge. I know SSIS has a sweet foreach loop container. Optimistically I fired up the Visual Studio designer, thinking that I would actually be able to figure this SSIS thing out pretty quick.

Wrong. Man I do have a desire to learn SSIS (well I at least tell myself I do) but every time I sit down to actually do it, I get flustered and think of an easier way to perform the task in a VBScript, DTS Package, etc.

I went back to Google thinking there had to be some freeware software out there to help with the import. The closest I found was some shareware version of an multi-file XML import. However with the shareware version you could only work with one file at a time. No thanks.

After uninstalling the shareware software, I stumbled on this article from Technet. This looks way to easy to actually work was my first thought.

Set objAccess = CreateObject(“Access.Application”)
objAccess.OpenCurrentDatabase “C:\Scripts\Test.mdb”
objAccess.ImportXML “c:\scripts\test.xml”, acAppendData

That’s it??? Really is it that simple? I fired up my Notepad++ and quickly modified the script to line up with my file paths. Double clicked on the resulting VBS file and poof like magic the XML files were importing. So then I just wrapped a Files Collection around it and whamo, I am watching wscript.exe do the rest. So simple.

Final Script:

Set objAccess = CreateObject(“Access.Application”)
objAccess.OpenCurrentDatabase “c:\Scripts\db3.mdb”
set fso = CreateObject(“Scripting.FileSystemObject”)
Set f = fso.GetFolder(“C:\XML”)
Set fc = f.Files
For Each f1 in fc
objAccess.ImportXML f1.Path, acAppendData
Next

select * from sysjobs

Result: Server: Msg 229, Level 14, State 5, Line 1
SELECT permission denied on object ‘sysjobs’, database ‘msdb’, owner ‘dbo’.

However using the stored procedure  sp_helprotect, I started to determine what access my test user had to each database. From BOL: SP_HELPROTECT: Returns a report with information about user permissions for an object, or statement permissions, in the current database. After running this against a user against on the master and msdb you quickly realize that the default created user has a lot of access.

The default user can glean the following information (and a lot more)

• Database file location, name, etc from sysfiles in msdb
• User information from sysusers
• User information from syslogins. Syslogins is interesting because if you do a SELECT * from it you get the permissions error. Inspection of the output from the sp_helprotect shows which columns in syslogins that you have access to. So just alter your select to select the fields you have access to.
• Information about objects from the sysobjects table
• Etc. Etc.

It feels like I am just scratching the surface. In the weeks to come I am going to set aside some time to come up with a security audit technique. Anyway, to continue on with my testing I then gave the user some fixed server roles. Tested some queries, rinse repeat, etc.

Lessons Learned (or re-learned):

• Do not give sysadmin fixed server role out unless it is absolutely justified.
• Default users with no access have quite a bit of access to the information about your server/database
• Used the database roles to give access to specific databases, used the fixed server roles to give access server wide.
• Be as granular as possible when diving out permissions
• Use the sp_helprotect stored procedure to audit what permissions a user has. Make sure application users do not have to many permissions.