Typically, it is possible to know how many lines a query returns by using COUNT(*).
In the same manner, is there any way know how many megabytes for example the output of a given query is ?
Something like
SELECT MEMORYUSE(*) FROM bla bla bla
EDIT : I like the *exec sp_spaceused ... * approach, as it can be scripted!
For completeness, there are a couple of options to give you more information about the executing / executed query that you can view / set using SSMS as well. As shown below, the rowcount for the query is shown in the bottom right of SSMS by default. Also, I've highlighted the advanced query options, which you can set globally as shown here. Of course, you can also turn any of these options on for the particular statement or batch by including them in the query, i.e. 'set showplan_test on', etc..
Also you can turn on 'show client statistics' in SSMS as shown below (with sample output).
If you're using SQL Server, turn on Client Statistics and you 'll find "Bytes sent from client" and "Bytes received from server"
Here is related question
SQL Finding the size of query result
I think this will be useful:
SQL Server Query Size of Results Set
I don't think there is anyway without creating a temp table for the results and checking the size.
Related
I have some heavy queries in my server and I want to copy the full query (more than 1024 characters).
But the field from view pg_stat_activity dont show me more than 2014.
I saw that I can change the postgres server parameter track_activity_query_size, but I dont want to restart my server to apply it, and I am not sure if it works really. So, there is another table, view, function, or something I want to find it? The full execution query.
Thanks!
All the views and functions that show the query string only seep a maximum of track_activity_query_size characters.
Unless you want to use the log file, as "a horse with no name" suggested, you'll have to restart the server.
When I execute a query for the first time in DBeaver it can take up to 10-15 seconds to display the result. In SQLDeveloper those queries only take a fraction of that time.
For example:
Simple "select column1 from table1" statement
DBeaver: 2006ms,
SQLDeveloper: 306ms
Example 2 (other way around; so theres no server-side caching):
Simple "select column1 from table2" statement
SQLDeveloper: 252ms,
DBeaver: 1933ms
DBeavers status box says:
Fetch resultset
Discover attribute column1
Find attribute column1
Late bind attribute colummn1
2, 3 and 4 use most of the query execution time.
I'm using oracle 11g, SQLDeveloper 4.1.1.19 and DBeaver 3.5.8.
See http://dbeaver.jkiss.org/forum/viewtopic.php?f=2&t=1870
What could be the cause?
DBeaver looks up some metadata related to objects in your query.
On an Oracle DB, it queries catalog tables such as
SYS.ALL_ALL_TABLES / SYS.ALL_OBJECTS - only once after connection, for the first query you execute
SYS.ALL_TAB_COLS / SYS.ALL_INDEXES / SYS.ALL_CONSTRAINTS / ... - I believe each time you query a table not used before.
Version 3.6.10 introduced an option to enable/disable a hint used in those queries. Disabling the hint made a huge difference for me. The option is in the Oracle Properties tab of the connection edit dialog. Have a look at issue 360 on dbeaver's github for more info.
The best way to get insight is to perfom the database trace
Perform few time the query to eliminate the caching effect.
Than repeat in both IDEs following steps
activate the trace
ALTER SESSION SET tracefile_identifier = test_IDE_xxxx;
alter session set events '10046 trace name context forever, level 12'; /* binds + waits */
Provide the xxxx to identify the test. You will see this string as a part of the trace file name.
Use level 12 to see the wait events and bind variables.
run the query
close the conenction
This is important to not trace other things.
Examine the two trace files to see:
what statements were performed
what number of rows was fetched
what time was elapsed in DB
for the rest of the time the client (IDE) is responsible
This should provide you enough evidence to claim if one IDE behaves different than other or if simple the DB statements issued are different.
I would like to be able to tag an SQL query somehow, so I can relate the query execution to the web request that triggered the query. I already have a unique request id, that I tag my logs and other monitoring with, so I can easily do a complete trace across the weblogs and new relic for example.
But when I look at a report of long running SQL queries for example, I cannot trace that back to the request that triggered the SQL Query. I would really like to be able to tag the query with my request id somehow.
I can't find anything online. When I search I just find blogs about storing tags and tag clouds in SQL. Not really what I need.
Hope the question makes sense.
This is a very interesting post...
I hope, adding an extra nullable parameter to your stored procedure(s) will ensure that the profiler will catch the unique id passed during a call (in the trace) whether you use that parameter inside the procedure or not (i.e. to do something meaningful...like inserting into an audit table with unique id, procedure name, timestamp etc).
But I think that will make life difficult as you now have to update all your procedures.
If you already have logging turned on (web server) and it captures the same unique id in its request (log file) along with a timestamp then you probably can code a small utility app that reads the log file and find matching entries in the traced table by the timestamp alone.
The only thing that might go wrong is if your web server and database server have differeing times (you need to offset your calculation accordingly).
I don't know if this will help but it is certainly a very interesting project and I am hoping somebody have experienced this thing and came up with a nice solution.
Will be closely watching this post if such a solution exists....
All the best...
If I understand correctly, you want to follow up the query execution in Activity Monitor. But have you considered using a DMV or SQL PROFILER ?
In my opinion, your best bet would be to wrap it in a stored proc. This way you will be able to FILTER your trace only for this object. Here's an example of a simple select and the same select wrapped in stored proc named sproc1 :
As you can see in this image, you can start a SQL PROFILER trace and filter it on the ObjectName. You can then add other column like CPU, StartTime, ...
If you can't use a stored proc, then I would suggest to insert a comment before the exec like this:
/* ID1234 */
select * from table1
Then use SQL PROFILER the same way but you now filter on the TextData using your ID
Here the result :
I am working with SQL right now and I am trying to write a bit of code that pulls a section of data from a database and saves it off to a file. This particular section of code is usually formatted all on one line and about 22,000-23,000 characters long on average. I can already pull some of the code but the pull stops after 4002 characters. My current code looks something like this:
SET HEADING OFF
SET ECHO OFF
SET LONG 100000
SET WRAP OFF
SPOOL output.txt
Select ________ (my select statement already works on its own);
SPOOL OFF;
I don't know the SQL language at all, I'm looking for some direction as to what functions I could research to help me out?
My end goal with this code is to be able to enter a value in, then have my code use that value to pull a value from one database. From there use both values to pull a long string of code from another database, would this kind of thing be possible in SQL?
Try adding this
SET SERVEROUPUT ON SIZE 1000000
I would really suggest that you try and view the SQLPlus Help.
It's really useful, and will explain all parameters to you, which is very useful.
Good Luck :)
In SQL Developer set
Tools > Preferences >> Navigate to Database > Worksheet > Max rows to print in a script(Increase number)
In PL/SQL Developer v7.1.x, is there way way to ignore large data types in queries or the "Query Data" feature. For example: If you right click on table FOO, and select "Query Data" this will execute a SELECT * FROM FOO. If that table contains BLOB data the query will take a while to complete and temporarily lock up the application. This is especially problematic when querying remote databases (for obvious reasons).
I would like a way to tell PL/SQL Developer not to retrieve large data by default. I know there is a way to limit the ResultSet size but this doesn't do what I am looking for.
I could just select each column I wanted ignoring certain ones but then I couldn't use the "Query Data" feature.
Thanks.
No, the Query Data feature does one thing and one thing only - queries all the data.
What you might find useful is that you can drag the name of a table or view from the Browser into a SQL Window, choose "Select" from the menu that pops up, and it will generate a SELECT statement on the table with all the column names included - but does not execute the query straight away. You can then edit it however you like (e.g. comment out the LOB columns) before you run it.
I know that Toad has something like that built in, but I'm not aware of a PL/SQL Developer option that disables BLOBS.
The option you are left with, for now, is to simply select all the columns individually and truncate the blob.
ie:
select foo, bar, trunc(baz,100) from foo where ...
Create a View that doesn't contain the blob column or whatever columns you don't routinely want to look at.