I'm using SQL Server Profiler for recording the activity of an software, which creates a ~50 GByte database with > 300 tables including the data. The Profiler saves the trace log into a table in a second database, which will be used for analysis later.
But, there is a problem with the memory usage of the SQL Server Profiler, because the application displays ALL (!) Traces in a table of the interface. As an result, the application needs more than 3 GByte after a few minutes. I don't have more than 50 GByte memory!
Is there a way to disable this table and only log into a table in the database? Also a command line tool which is able to record the same information would be great.
There are a whole load of stored procedures/functions, etc, for creating traces, without using the SQL Server profiler UI. There are too many to list them all here, but the root of the documentation is Introducing SQL Trace. You should hopefully be able to find the right combination to call to get the trace you want.
These server-side traces have to be stored to file, rather than into another table, but you can always import them into a table later if you need them there for analysis.
Related
We're having some queries in an Azure SQL database that are occasionally running very slowly. The issue has been difficult to properly diagnose, as the same queries will run fine at other times, even when the server is under a similar load.
To help, I'd like to be able to view log information for the server. If I could see a list of transactions, by time, and their outcome (completed, terminated/rolled back, etc) I believe it would be helpful. Several other SQL pages seem to allude to log-files you can access, but since this is an Azure SQL instance, there isn't a physical server I can just download a file from.
I know I can query sys.event_log to see when particular events are occurring (and in fact, I do see a high amount of deadlocks around our problem times), but I'm unaware of any way to see what query's were being handled at the time of these locks.
I'd like to be able to view log information for the server. If I could see a list of transactions, by time, and their outcome (completed, terminated/rolled back, etc) I believe it would be helpful.
The log information you are trying to view is not helpfull.
You can view slowly running queries running using the same manner like on premises using DMV's
You can also enable query store ,which can you show you different stages of query .This i think will help you more in troubleshooting slow queries and is not tied to Premium Databases only
I use "Lexware Warenwirtschaft Premium 2014" (a well-known merchandise management software in Germany). It uses Sybase as a database. I connect to the database by using a ODBC connection(SQL Anywhere driver). The database has 800+ tables. For example when Lexware creates a new Article, it writes data into different tables.
Is there a way to track into which tables Lexware wrote data?
As an ad-hoc measure you could switch on ODBC tracing, and then review the contents.
http://support.microsoft.com/kb/274551 tells you how to do this from a Windows client, and you can find similar information for Linux/Unix and other clients.
You'd then have to parse the trace file to see which queries were inserted into. The first step would probably be to isolate all the SQLPrepare and SQLExecDirect statements, and check them for INSERT, UPDATE and other relevant Sybase statements.
Note that this is not something you'd want as an ongoing solution, just a way to find out what an ODBC client does if you do not have access to e.g. logging information on the database itself. However, the trace slows down execution and would generate a very large trace file if you left it running for any significant period.
I don't think so. Whatever this program does behind the interface is hidden in its binaries and unreadable for humans, so you can't read the code to see which tables are altered.
You might be able to figure out which table was edited last, depending on the SQL-Server and it's version.
I have a delicate situation wherein some records in my database are inexplicably missing. Each record has a sequential number, and the number sequence skips over entire blocks. My server program also keeps a log file of all the transactions received and posted to the database, and those missing records do appear in the log, but not in the database. The gaps of missing records coincide precisely with the dates and times of the records that show in the log.
The project, still currently under development, consists of a server program (written by me in Visual Basic 2010) running on a development computer in my office. The system retrieves data from our field personnel via their iPhones (running a specialized app also developed by me). The database is located on another server in our server room.
No one but me has access to my development server, which holds the log files, but there is one other person who has full access to the server that hosts the database: our head IT guy, who has complained that he believes he should have been the developer on this project.
It's very difficult for me to believe he would sabotage my data, but so far there is no other explanation that I can see.
Anyway, enough of my whining. What I need to know is, is there a way to determine who has done what to my database?
If you are using identity for your "sequential number", and your insert statement errors out the identity value will still be incremented even though no record has been inserted. Just another possible cause for this issue outside of "tampering".
Look at the transaction log if it hasn't been truncated yet:
How to view transaction logs in SQL Server 2008
How do I view the transaction log in SQL Server 2008?
If you want to catch the changes in real time, I suggest you consider using SqlDependency. This way, when data changes, you will be alerted immediately and can check which user is using the database at the very moment (this could also be done using code).
You can use this code sample.
Coming to think about it, you can establish the same effect using a trigger and writing ti a table active users. Of course, if you are suspecting someone is tempering with data, using SqlDependency might be a better way to go with, as the data will be stored outside of the tampered database.
You can run a trace, for example a distant profiler trace, that will get all SQL queries containing the DELETE keyword. This way, nobody will be aware that queries are traced. You can also query the default trace regularly to get the last DELETE commands: Maintaining SQL Server default trace historical events for analysis and reporting
My boss and I have been trying to see what sort of auditing plan we could try for our stored procedures. Currently there're two external applications taking information from our database through stored procedures and we're interested in auditing when they're being executed, and what values are passed as parameters. So far what I've done is simply create a table for the stored procedures one of the apps is using, and as they use the same input parameters, have one column per parameter. Obviously this isn't the best choice, but we wanted to get quick info to see if they were running batch processes and when they were running them. I've tried SQL Server Audit, but it doesn't catch the parameters unless you're executing a SP in a query.
SQL Server Profiler will do this for you; its included for free. Setup a trace and let it run.
You can also apply quite a bit of filtering to the trace, so you don't need to track everything; you can also direct the output to a file, or sql table for later analysis. This is probably your best bet for a time limited audit.
I think I've used the SQL Server Profiler (http://msdn.microsoft.com/en-us/library/ms181091.aspx) in the past to audit SQL execution. It's not something you would run all the time, but you can get a snapshot of what's running and how it's being executed.
I haven't tried using them, but you might look at event notifications and see if they will work for you.
From BOL
Event notifications can be used to do the following:
Log and review changes or activity occurring on the database.
Is there any system defined sp is available in SQL Server 2005, to find what are the tables are got affected when the applicaion is running and we are navigating from one page to other.
There's really no easy way (if any at all) to find that out, unfortunately.
As SQL Server MVP Aaron Bertrand puts it in his excellent blog post When was my database / table last accessed? :
A frequently asked question that surfaced again today is, "how do I see when my data has been accessed last?" SQL Server does not track this information for you. SELECT triggers still do not exist. Third party tools are expensive and can incur unexpected overhead. And people continue to be reluctant or unable to constrain table access via stored procedures, which could otherwise perform simple logging. Even in cases where all table access is via stored procedures, it can be quite cumbersome to modify all the stored procedures to perform logging.
However, with the help of the sys.dm_db_index_usage_stats DMV (dynamic management views) function and some clever T-SQL programming by Aaron, you can find out a few of those answers - check out his very enlightening blog post for details !
However: since this information is based on a DMV and the "D" in DMV stands for dynamic, those values are only valid since the last server reboot and will be wiped out and not preserved when you next have to restart your SQL Server process / reboot your server machine.
I know of none, but Profiler offers a solution. Run Profiler (can be a developer box) and navigate. It will create an output file for you of what is being run.
There are also code tools that show dependencies. I would imagine at least one shows dependencies on SQL objects.
I don't think so. You can run the SQL-profiler to see which commands are fired against the SQL server but you will have to parse them yourself.
You could also try to empty the query cache and then look at it when your navigation is done, but this cache will be contaminated by other queries running on the server (including the ones run by SQL server itself).