Does Oracle 10 support a short circuit evaluation query? if yes, there are some special key for use it?
You are probably talking about short circuit evaluation.
A DBMS has cost-based optimizer. There is no guarantee wich condition will get evaluated first and there's no special key to activate this.
Note that PL/SQL does use short circuit evaluation
The only short circuit I have seen Oracle do, relates to NVL vs COALESCE.
SELECT NVL(1,1/0) FROM DUAL
SELECT COALESCE(1,1/0) FROM DUAL
NVL evaluates both sides and throws an error, the coalesce doesn't.
It also looks like decode is doing the same thing:
SELECT decode(1,1,9,2,1/0) FROM DUAL
It isn't evaluating the second part so avoids throwing an error.
On the SQL Server optimizer, I know that the query engine can rewrite these kind of statements and cause problems with short circuit examples like this so as a general rule - you should never rely on a short circuit within your logic - I do not know if the same applies to Oracle - I suspect it will.
Related
Recently I faced with the problem that some (theoretically irrelevant) formal changes in the code of a function (even adding or removing a space character to or from the code) can greatly affect the performance of the function. (see my previous questions here and here).
The mystery was solved by Jon Heller as
If adding spaces to the code changes performance, this is likely a
plan management issue. Many Oracle tuning tools operate on the SQL_ID,
which is like an MD5 hash of the SQL text. So if you change a single
character of the SQL text, the optimizer treats the code like a brand
new statement. Any plan management fixes, like a SQL profile, or plan
outline, will not be applied to the new statement. Maybe a DBA tuned
an old statement with an /*+ INDEX... */ hint, but that hint isn't
carried over to the new statement. Compare the Note sections in the
DBMS_XPLAN output.
and as
A space in a SQL statement would change the SQL_ID, which could cause
the optimizer to no longer match the SQL statement with plan
management features like profiles, outlines, baselines (possibly -
they're supposed to be able to avoid this problem in some cases),
patches, advanced rewrites, etc.
So the only question I have left is how can I get rid of the stuck bad execution plans? How can I "clean" Oracle from them?
This worked for me:
alter system flush shared_pool;
I am in an odd situation where I must prevent SQL injection with a string query using REGEXP_LIKE in Oracle. I cannot use a prepared statement because of a performance problem. Oracle is taking twice as long to process the query which is causing timeouts in our production environment when a prepared statement version is used.
Normally I'd use something like oracle's escape operators { and } but in this case they have meaning in a regular expression and don't seem to work. Aside from single quotes, what would I need to guard against for a regular expression case like this?
Query example
SELECT * FROM table where somecolumn = 2 and regexp_like(column, '\Wmy text\W|\Wfoo\W');
While I've seen other questions about manual protection from sql injection, none dealing with regular expression cases like this.
Would a q escape work like this?
SELECT * FROM table where somecolumn = 2 and regexp_like(column, q'[\Wmy text\W|\Wfoo\W]');
I am facing an ORA:7445 issue with auto sql tuning advisor. Auto sql tuning advisor keeps failing with
ORA:7445
while it's tries to tune a particular SQL.
Is there any way to skip this sql statement from auto sql tuning advisor job?
The simplest way to avoid the Automatic SQL Tuning Advisor may be to convert the query into a form that is not supported by the program.
According to the "Automatic SQL Tuning" chapter of the "Database Performance Tuning Guide":
The database ignores recursive SQL and statements that have been tuned
recently (in the last month), parallel queries, DML, DDL, and SQL
statements with performance problems caused by concurrency issues.
If the query select * from dba_objects was causing problems, try re-writing it like this:
select * from dba_objects
union all
--This query block only exists to avoid the Automatic SQL Tuning Advisor.
select /*+ parallel(dba_objects 2) */ * from dba_objects
where 1=0;
It is now a "parallel query" although it will not truly run in parallel because of the 1=0. I haven't tested this, and I imagine it will be difficult for you to test, because you'll need to flush the existing AWR data to prevent the errors.
This is one of the reasons why I usually disable the Automatic SQL Tuning Advisor. I like the idea of it, but in practice I've literally never seen the tuning advisor provide useful information. All it has ever done for me is generate alerts.
In theory,the package DBMS_AUTO_SQLTUNE contains the parameters BASIC_FILTER, OBJECT_FILTER, and PLAN_FILTER. I assume one of those could be useful but I don't think they are implemented yet. I can't find any references to them on Google or My Oracle Support. And when I entered random text for the values there were no errors.
Ideally we would look up every ORA-00600 and ORA-07445 error, create an SR, and fix the underlying problem. But who has time for that? when you encounter a database "bug", the best solution is usually to avoid it as quickly as possible.
I've isolated a very specific code piece that works on our HP-UX Oracle 11.2 environment, but fails on our RHEL 7.1 Oracle 11.2 environment. Any pointers as to why this would happen?
Everything else (except PSU level) is generally the same.
TIA
AND v_effective_date
BETWEEN DECODE
(pet.attribute1,'OVERTIMEVACCOMP',
fnd_date.canonical_to_date(prv2.result_value),
TO_DATE ('01/01/0001', 'DD/MM/YYYY'))
AND DECODE
(pet.attribute1,'OVERTIMEVACCOMP',
fnd_date.canonical_to_date(prv3.result_value),
TO_DATE ('01/01/0001', 'DD/MM/YYYY'))
Most Entity-Attribute-Value models have a fatal flaw: stringly-typed data.
If all values are stored as strings it's critical that attribute filtering occurs before those values are converted into a type. But Oracle's query optimizations make it almost impossible to enforce a specific order of operations in SQL.
This question has a simple example of how bizarre this out-of-order execution can get. It's a bit extreme, but will hopefully help you prove how unpredictable order of operations can be. You wouldn't think this query could fail, but it does:
WITH data AS (SELECT 1 AS cond, 10 AS num, 0 AS div FROM DUAL)
SELECT
CASE WHEN cond = 2 THEN (CASE WHEN MAX(div) = 0 THEN 0 ELSE SUM(num / div) END)
ELSE -1
END AS result
FROM data
GROUP BY cond;
ORA-01476: divisor is equal to zero
We don't know exactly how Oracle implements the order. Maybe it's different between RHEL and HPUX, maybe it's different on Thursdays. Unfortunately, even using a LEAST may not be bullet-proof. That function may logically operate in order, and it may normally use short-circuit evaluation, but it's not guaranteed to always run in that order. You may have just switched between one 99.9% solution to another 99.9% solution.
There are only two fool-proof solutions to this, discussed in more detail in my answer here. Either change the table to use a different column for different types or add an inline view with a ROWNUM to every query. Neither of which is pleasant.
I occasionally encounter examples where SELECT...INTO...FROM DUAL is used to call a function - e.g.:
SELECT some_function INTO a_variable FROM DUAL;
is used, instead of
a_variable := some_function;
My take on this is that it's not good practice because A) it makes it unclear that a function is being invoked, and B) it's inefficient in that it forces a transition from the PL/SQL engine to the SQL engine (perhaps less of an issue today).
Can anyone explain why this might have been done, e.g. was this necessary in early PL/SQL coding in order to invoke a function? The code I'm looking at may date from as early as Oracle 8.
Any insights appreciated.
This practice dates from before PLSQL and Oracle 7. As already mentioned assignment was possible (and of course Best Practice) in Oracle7.
Before Oracle 7 there were two widely used Tools that needed the use of Select ... into var from dual;
On the one hand there used to be an Oracle Tool called RPT, some kind of report generator. RPT could be used to create batch processes. It had two kinds of macros, that could be combined to achieve what we use PLSQL for today. My first Oracle job involved debugging PLSQL that was generated by a program that took RPT batches and converted them automatically to PLSQL. I threw away my only RPT handbook sometime shortly after 2000.
On the other hand there was Oracle Forms 2.x and its Menu component. Context switching in Oracle Menu was often done with a Select ... from dual; I still remember how proud I was when I discovered that an untractable Bug was caused by a total of 6 records in table Dual.
I am sorry to say that I can not proof any of this, but it is the time of year to think back to the old times and really fun to have the answer.