In the SQL Server Audit Add DB User Event Class, there are four Event Sub Classes defined:
Add
Drop
Grant database access
Revoke database access
(MS documentation found here)
When I set up SQL Server Profiler to trace the Audit Add DB User Event Class, it only seems to capture events with a subclass of 3 or 4, and not 1 or 2.
To test the trace, I am using the following SQL statements:
CREATE USER testuser FOR LOGIN testlogin;
DROP USER testuser;
When I run these statements in SQL Server Management Studio, SQL Server Profiler displays two Audit Add DB User Events, one with EventSubClass 3 (Grant database access) and one with EventSubClass 4 (Revoke database access), but does not display anything for EventSubClass 1 (Add) or EventSubClass 2 (Drop).
From what I can tell, all three even subclasses should be covered by the SQL statements used above. Is there something additional that needs to be configured in order to capture these event subclasses?
The old trace functionality has been deprecated since 2012. I did some testing and depending on what commands I executed I could get 2. But I never managed to get 1. If you look at the documentation for this event class, you'll see that it is documented to provide information when you use the ancient procedures sp_adduser, sp_dropuser, etc. But even when doing that it seems a bit flaky.
Sure, one could report this to MS, but they will (most likely) just say that you should use a technology which isn't deprecated. I.e., Extended Events. I very much doubt that MS will pour any resources into fixing this, even if that would consider this to be a bug in the first place. So, my recommendation will be the same: Look into Extended Events instead.
Here's a blog I wrote about "getting into" XE: http://sqlblog.karaszi.com/tips-for-getting-started-with-extended-events/
Related
Any simple way of solving the problem where you have a component and get the same log massage more than one time due to the fact that the component is nested inside other components (like a container and a data flow for example)
I found this, where MS say it wont do anything about it, but its from 2007.
I dont really want to do the workaround suggested, seems a lot of work.
For logging, if you chose to log to sql server, SSIS will create a Stored Proc
(SQL 2005)
Proc Name: dbo.sp_dts_addlogentry
Table Name: dbo.sysdtslog90 (user table)
(SQL 2008)
Proc Name: dbo.sp_ssis_addlogentry
Table Name: dbo.sysssislog (system table)
You are free to modify this to filter out log entries (sql will recreate it if it is missing, but will not overwrite a self written version of the same name.)
The system generated version is simply an insert into of the parameters sent to the proc by SSIS.
You can add logic to follow the chain up the executionid to find parent objects and suppress logging for entries that have already been logged (you will want to handle the OnError event name in your code for this) I usually pass OnPreExecute, OnPostExecute, OnError, and OnTaskFailed events into my logging proc. By default, the proc also gets PackageStart and PackageEnd events.
That being said, I let all of these log fully to the table in sql then use summary and detail report to check the logging and see errors. My report filters to show only the one error for each occurance rather than filtering on the input into the log file. I also log all of my SSIS packages into a single database for configurations and logging that is included in every SSIS package.
The Current Action cannot be completed because the user data source credentials that are required to execute this report are not stored in the report server database
Take a look at your datasources for your reports. There are two settings.
User can supply them.
Or they can be stored in DB.
They need to be stored in DB for subscriptions (at least that's how the error reads). See if you can modify your datsources.
please ignore if you had already solved it.
This issue may also happen if default user credentials (like windows userID) do not have enough permissions to run a piece of SQL script or a SP. We can go to SQL server report configuration and select an option to ask for credentials every time you run a report.
You can provide the correct user id paswd when prompted?
Praveen
What am I missing here? The queries I see in SQL Server Profiler are all targeted against the master database, which makes it difficult to filter by database name ... which event or events should I be watching so I can filter by database name.
The bigger question, what exactly is going on here?
You should remove this 'MultipleActiveResultSets=True' from your EntityFramework connection
string
after that, you can see the target database name show in the Profiler , instead of master.
In my option, maybe ADO.NET team want to make use the MultipleActiveResultSets feature to get
data from DB, so they have to access master.
MultipleActiveResultSets is about raise one query and don't return all its result (like in foreach statement in LINQ) , and in the same time ,raise another query to get another data in the same session.
By default, this behavior is not allowed by DB. SO.....
I was able to get around this issue, including leaving MARS active by adding an application name to my connection string:
Data Source=database_server;Initial Catalog=MyDatabase;Trusted Connection=true;MultipleActiveResultSets=True;Application Name=MyDatabase;
Then you can filter on application name.
If this is for SQL Server 2008 R2, in your trace properties, on the 'Events Selection' tab, check 'Show all columns'. You should then be able to create a column filter based on DatabaseName.
I believe you'll have to pause or stop your trace to make these changes.
As K Ivanov pointed out, having MARS (MultipleActiveResultSets) enabled will show the DatabaseName as master in SQL Profiler. By setting this to false, it'll show the proper DatabaseName, but then you lose the ability to have MultipleActiveResults.
you can use LoginName or HostName to filter in the profiler
For some reason, if I select the SP:CacheHit event, it now shows the queries against the correct database and I am able to filter by it. What is that event exactly?
I Need to find out what are all the applications that use my sql server.
I'm using Profiler trace to do this (if there's another way to do this I would appreciate it)
On Profiler I'm using a Replay template, and after looking at the trace result I see that there's a column called Application Name, I'm wondering if there's a way to get the distinct ones (the trace is on a .trc file).
(By the way is this supposed to be posted on stackoverflow or serverfault?)
Thanks,
Gabriel
Try this:
SELECT DISTINCT ApplicationName
FROM ::fn_trace_gettable('C:\YourFolder\YourTraceFile.trc', DEFAULT) t
You can actually do this right from within Profiler in SQL Server 2008.
Create a trace with the following two events:
Security Audit : Audit Login
Security Audit : Existing Connection
For those two events, capture the following columns:
Event Class
Application Name
SPID (required)
Event Sub Class
Add a filter to Event Subclass to restrict it to values of 1. This filter will only capture non-pooled logins. This should give you all your existing connections and any new logins that occur during the time you are running your trace.
Next, in the organize columns, move Application Name up to the "Groups" section. This will now group all the results by the Application Name.
This is a pretty light weight trace and shouldn't put much (if any) load on the server if you restrict it to just those events and apply the filter.
(I'm pretty sure previous versions work the same way. I just don't have one in front of me to test.)
Following on from my last question:
I've written some code to upgrade a SQL Server database. Before I upgrade the database, I plan to limit access to the database with the following statement:
ALTER DATABASE Test SET SINGLE_USER WITH ROLLBACK IMMEDIATE
Before running this code, I'll give the user an opportunity to opt out. At the time of prompting the user, I thought it would be nice to show the list of active connections (continuously polled at a set interval); providing the user with a tool to identify applications/users they would like to boot off the server before proceeding.
In SQL 2000, you can use the sys.sysprocesses table to see all connections that apply to a database. This includes connections that have no active request (like when you open a Query Analyser window and select a database).
However, using:
sys.dm_exec_connections
sys.dm_exec_sessions; and
sys.dm_exec_requests
I couldn't figure out a way to achieve the same outcome. It appears that these views only tie connections to a database through a request. Is there a way to mimic the behaviour of sys.sysprocesses? I'd prefer not to use this table for SQL Server 2005/2008 databases.
Er... I recommended these for your other question.
Sorry, but, I've found out that you still have to use sysprocesses
It's logged as a bug in Microsoft Connect 144515 to be fixed, I found it here
Personally, I still use sysprocesses because I'm comfortable with it, however lazy and luddite that may be...