I have been asked to find the log of all of the queries submitted by user name and see the length of time it take for each queries to run. I understand that there is a web based interface that list this, but we are looking to be able to query it within the Netezza environment. We don't have to see the actual queries perse just the average run time.
The nz_query_history table contains all the query runtime information including the actual sql command.
select *
from dba_monitor.admin.nz_query_history
Related
I would like to know that where does Query Store stand and store execution plan, runtime statistics information? I researched how does SQL Server compile, execute query and in which part Query Store works and how it works. But I could not get enough information where it stand and for its Max Size feature where it store all information.
Thank you
If query store is enabled SQL stores the information in system db views you can query these views to retrieve the configuration and status of query store.
SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
max_storage_size_mb, readonly_reason
FROM sys.database_query_store_options;
or to see all
SELECT * FROM sys.database_query_store_options;
Here's the issue.
I'm using Oracle 11g Database.
I have a master table that has rows in lacs and is in use almost the entire working day. We have a monthly activity where we dump all production data into staging(testing) db. Now whenever I execute a select query to retrieve data of consumer based on a their address, the time taken on staging db is 3 seconds and 50-60 seconds on production server. All the necessary indexes are in place. No issues in the procedures being called. Stats have been gathered. Indexes have been rebuilt.
I need to know the following:
Is it because that the table on production is busy the entire day?
Does it have anything to do with buffer cache or any other database parameter?
Also, I would like to mention that we use the "LIKE" operator in where condition to search consumer based on a particular address. However, we are also using % as a prefix i.e. for example, select * from master_table where m_address like '%variable_name%'. Now I have read that Oracle might omit the use of index if the % wildcard is used as prefix i.e. before the character. However, the astonishing factor is that it runs perfectly fine on my Testing environment as previously mentioned.
Pl help. Let me know if you need more info.
Is there a way to log any query every time one is executed and store information about it in a table? When someone executes a query, it would be looked at, If the query contains something specific in it then the query, the user who executed, and time it was executed would be stored in a table.
The only way I could see doing this right now is to have a stored procedure fire every X-amount of time to troll the query history. When one is found it is stored in the log table.
This Stackoverflow thread mentioning various ways to view query history in SQL Server Management Studio might be helpful to you.
One easy third-party tool that enables this functionality (albeit saving to an XML file not a SQL Server table) is ApexSQL Complete. More details here.
I am running a complex database query that takes enough time.
First I am unloading the results into a file and then I am running this query again to delete all those entries. This again takes lots of time.
Is there a better way so that I can save time here and fulfill both the purposes.
I am new to databases..dont have idea whether there is a way.
Thanks !!!
You must find bottleneck in your query or process: is it SQL query or saving data to slow media?
If it is SQL query then try to find what part of this query takes most of the time and for example add some indexes to make it faster. Have a look at similar question: Tweak Informix query . Remember that SET EXPLAIN is your friend. Also remember to UPDATE STATISTICS after you change a lot of data in database.
Why do you unload the results into a file? Do you analyze those results with different tools? If so then maybe there is a way to do it more efficiently in SQL?
I recently decided to crawl over the indexes on one of our most heavily used databases to see which were suboptimal. I generated the built-in Index Usage Statistics report from SSMS, and it's showing me a great deal of information that I'm unsure how to understand.
I found an article at Carpe Datum about the report, but it doesn't tell me much more than I could assume from the column titles.
In particular, the report differentiates between User activity and system activity, and I'm unsure what qualifies as each type of activity.
I assume that any query that uses a given index increases the '# of user X' columns. But what increases the system columns? building statistics?
Is there anything that depends on the user or role(s) of a user that's running the query?
But what increases the system columns?
building statistics?
SQL Server maintains statistics on an index (it's controlled by an option called "Auto Update Statistics", by default it's enabled.) Also, sometimes an index grows or is reorganized on disk. Those things come in under System Activity.
Is there anything that depends on the
user or role(s) of a user that's
running the query?
You could look into using SQL Server Profiler to gather data about which users use which indexes. It allows you to save traces as a table. If you can include index usage in the trace, you could correlate it with users. I'm sure the "showplan" would include it, but that's rather coarse.
This article describes a way to collect a trace, run it through the index tuning wizard, and analyze the result.