Quantcast
Channel: Toad for Oracle Forum - Recent Threads
Viewing all 4385 articles
Browse latest View live
↧

RE: Different behaviour in TOAD than in SQLPlus?

January 29, 2018, 1:30 am
$
0
0

Actually it's even weirder.

Imagine the statement like this (obviously that's not the actual statement):

variable var1 number;

begin
  :var1 = 123;
end;
/

select x from y where field=:var1;

If I run this as a script (F5), so it runs like it would in SQLPlus, it's slow (>6 minutes).

If I only run the sql statement (F9) and pass the bind variables through TOADs bind variable dialog, it's fast (~1 second).

So the question is not "what does TOAD different from SQLPlus", it's "what does TOAD different when executing statements as a script".

↧
Search

TOAD User Group meeting or conference

January 29, 2018, 2:42 am
$
0
0

A few years back I attended a couple of meetings organised by Quest - even had my photo taken with a lifesize Toad!

Do these still get organised from time to time?

Is there anything due or planned?

↧
↧

Exchange connections in Workspaces

January 29, 2018, 4:53 am
$
0
0

Hello,

I'm a heavy user of the workspace feature of toad. Now our DBAs are planing to replace the connection strings in the tnsnames.ora (because the host name will change due to a hardware upgrade). Unfortunately My saved editor tabs do not load as long as the connection for them is not established. Therefore I will not be able to open my saved editor tabs.

I've tried to search & replace the connection strings in the file "Workspaces.dat" which rendered it unreadable for Toad.

Is there any way to replace the connections for the saved workspaces?

Best regards
Quirks

↧

RE: Different behaviour in TOAD than in SQLPlus?

January 29, 2018, 5:13 am
$
0
0

When doing a select using F9, it doesn't return the entire data set immediately.  What it's doing is getting what can be stored in the OCI buffer and displaying that.  Each time you scroll down on the data grid, it can grab more data as needed.

Using F5, the entire data set has to be returned.  This is designed to emulate the functionality of SQL*Plus as closely as possible. If you think about running a script, there are many things in SQL that can change how the output looks (COL, LINESIZE, ...).  

For your situation, you want to run F5 to emulate what you're seeing outside of Toad.

↧

RE: Different behaviour in TOAD than in SQLPlus?

January 29, 2018, 5:23 am
$
0
0

The default buffer size is 500 rows. The statement returns 90 rows, in both cases all rows are returned. I can also change the select clause to "count (*)" which means the statement only returns one row with one column, and the performance issue persists.

It also doesn't matter to me how the output looks. It matters to me how the performance differs between 1 second and >6 minutes, even though it's the same select statement with the same bind variables.

We are developing, optimising and debugging complex statements in TOAD. How can we continue to do this if they don't behave the same way they behave outside of TOAD?

↧
↧

RE: Different behaviour in TOAD than in SQLPlus?

January 29, 2018, 5:27 am
$
0
0

I observed such differing behavior with rarely dramatic changes execution times too.

To me it seemed that sqlplus.exe always was similar to our Automatic Job execution, but sometimes different than Toad. Though the side that runs faster is not always the same, so it can be tricky to develope OLTP/Batch queries with the best performance.

Also I remember one rather short query, that was even illegally transformed (concerning joins) on one side and could not run, as it went smoothly on the other side, so I had to force NO_QUERY_TRANSFORMATION hint. Sadly I don't recall which side was Toad.

↧

RE: Different behaviour in TOAD than in SQLPlus?

January 29, 2018, 5:33 am
$
0
0

if you want to see how it's going to behave outside of Toad, then you should be using F5 for this.  This is evident when you say that F5 and SQL*Plus are acting the same way.

To optimize, I would also recommend using SQL Optimizer to see if the performance can be improved.  Also look at the explain plan to see where your bottleneck is.

↧

RE: Different behaviour in TOAD than in SQLPlus?

January 29, 2018, 5:49 am
$
0
0

Gregory, that's going in circles. The question is WHY does the same statement, with the same bind variables, perform vastly different in TOAD when executed as a query, compared to when executed as a script (or when executed outside of TOAD)? There has to be a logical explanation for this, it's not magic.

I can't go and tell 20 developers "from now on, only run your queries with F5". They're not going to do it, because 99% of the time you need to actually be able to actually read the output. Script execution via F5 is for running scripts (e.g. a series of update statements), it's not optimal for working with a single select statement.

↧
Search

RE: Different behaviour in TOAD than in SQLPlus?

January 29, 2018, 6:01 am
$
0
0
What you need to tell your developers is that if they want to emulate how a query will work in an outside environment, then they need to use F5 because that's going to mimic that behavior
 
F9 is designed to give you a small subsection of your output in grid format.  It's not designed to give you the entire data set at once.  F5 (and SQL*Plus) also has to allocate enough memory to accommodate the maximum amount of data for a row.  If you have a bunch of VARCAR2(4000) columns, that total amount of space has to be allocated.  F9 optimizes that as much as possible. 
 
F9 - designed to get data as quickly as possible into the IDE grid
F5 - SQL*Plus and outside app emulation.
 
They are designed for different purposes so in your case, you need to tell the devs to use correct tool for the job that they're trying to accomplish.  Yes it's called script execution but it's also the way external apps are going to behave.
 
↧
↧

RE: Different behaviour in TOAD than in SQLPlus?

January 29, 2018, 6:02 am
$
0
0

Did tracing of the sessions reveal anything?   If you aren't sure, post the trace files.

If they are too big to post, zip them up and email them to me.   john.dorlon@quest.com

↧

RE: Different behaviour in TOAD than in SQLPlus?

January 29, 2018, 6:28 am
$
0
0

John, the issue was in the meanwhile "fixed" by re-analyzing all tables involved. It's now fast no matter what way we execute the query. So sadly I can't reproduce the issue anymore and therefore I'm unable to provide traces :-(

But I still have to follow up the issue with the different execution times. Gregory says that "execute single statement" behaves fundamentally different from "execute as script". I'm not happy with that, but if that is the case we'll have to accept that and draw our conclusions from it. However you said earlier that you can't think of any difference apart from the array buffer size. Those two statements are conflicting.

Again: If the bottom line is that quest has optimized the "execute single statement" so well that it's able to fetch data > 300x quicker (in some cases, like the one at hand) then I can't do much but congratulate you and move on. But if the root difference is that for example the optimizer is parameterized differently in F9-mode, I'd like to know.

↧

RE: Different behaviour in TOAD than in SQLPlus?

January 29, 2018, 7:16 am
$
0
0

> John, the issue was in the meanwhile "fixed" by re-analyzing all tables involved.

Ah-hah!   Well, clearly then, the two different ways of executing the query produced different execution plans.   That's the difference.

  The optimizations that Greg was talking about refers to fetching and presenting the data after the query is executed.   I don't think that was the key difference here (especially since you said the problem still happened when you did a "select count(*)" instead of fetching all rows).    Oracle is in charge of the execution of the query, not Toad.   Some difference (maybe just some small whitespace difference, maybe the way a variable was handled) caused Oracle to create a new execution plan, and because of out-of-date table statistics, the execution plan was inefficient. 

  Even if the two methods are now producing the same EP, you could still perhaps gain some insight as to what is different by tracing the session.   I just did a quick test and got the same SQLID when run with F5 compared to F9, but I don't think that was the case for you.

-John

  

  

↧

RE: Different behaviour in TOAD than in SQLPlus?

January 29, 2018, 7:48 am
$
0
0

That makes sense. I do see one difference: When executing the statements with F5, I declare one variable as NUMBER and one as VARCHAR2(100):

variable firmanr number;
variable id varchar2(100);

begin
  :firmanr:=11;
  :id:='TAKS12145.0';
end;
/

select .....

When executing the query with F9, in the bind variable pop up, both variables are declared as VARCHAR2.

However, I just traced TOADs execution of the query, and in both cases (F9 or F5 execution) ended up with the same SQLID. The different data types of the bind variables do not seem to force a different SQLID. So whatever effect caused a different execution plan before does not seem to happen anymore.

The bottom line is TOAD doesn't really do anything different when executing statements via F9 or F5, but we still ended up with a different plan. The reason for that can't be explained, because we can't reproduce it now that the tables are re-analyzed and the underlying issue is fixed.

I'll look into this some more if we have this effect again, and that time take the traces before fixing/working around the underlying issue (urgency permitting), maybe we'll find the problem then.

Thank you for your help!

↧
↧

RE: Toad for Oracle Base edition

January 29, 2018, 10:16 am
↧

RE: Toad for Oracle Base edition

January 29, 2018, 10:19 am
↧
Search

Toad for Oracle Base edition

January 22, 2018, 8:13 pm
$
0
0

Toad for Oracle 12.12 Base edition have SQL history , and Create Scheduler Job ?

↧

RE: statspack snapshot

January 29, 2018, 1:42 pm
$
0
0

Just click one (so it turns blue) then ctrl+click the one above or below it (so it is also blue).    

↧
↧

RE: statspack snapshot

January 29, 2018, 1:51 pm
$
0
0
Did that – selected 3 – the graph came up but no advice when I clicked the advice tab
 
Bev
 
Beverley K Belk
RX/MMA - Oracle DBA
 
St. Louis, MO
Office   314-387-5298
CELL    314-346-5401(pager)
14100 Magellan Plz # 400 
Maryland Heights, MO 63043-4644
1-866-915-5643 (DBA On-Call) || mmaOracleDbaPager (DBA On-Call Pager)
 
↧

RE: statspack snapshot

January 29, 2018, 1:54 pm
$
0
0

It only works with two nodes selected, not three.

There may (or may not) be any useful advice - it depends on the wait events that were found between the first and 2nd selected snapshot.

-John

↧

RE: statspack snapshot

January 29, 2018, 2:13 pm
$
0
0
No matter what parameter I select
When I do the two snapshots I always get
 
Snapshot interval too long.
Snapshot intervals greater than 30 minutes make it harder to identify noteworthy events.

Top Wait: log file parallel write
No advice on this event.
 
Bev
 
Beverley K Belk
RX/MMA - Oracle DBA
 
St. Louis, MO
Office   314-387-5298
CELL    314-346-5401(pager)
14100 Magellan Plz # 400 
Maryland Heights, MO 63043-4644
1-866-915-5643 (DBA On-Call) || mmaOracleDbaPager (DBA On-Call Pager)
 
↧
Viewing all 4385 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>