Is there a view (or other method) in Oracle, from which I can extract the failed sql statements, which were executed by the user? I tried to check v$sql but, as it turned out, it contains only the successful ones. I'm using Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production.
Thank You.
Blaim me if I'm wrong but as far as I understand sql gets logged on shared pool check and statements Laszlo mentioned select nonexistingcolumn from dual; failed on semantic check. My answer is you won't find invalid statements in DB.
https://docs.oracle.com/database/121/TGSQL/tgsql_sqlproc.htm#TGSQL178
Related
I am trying to install a stored procedures. When I run the query I get Incorrect syntax near the keyword 'tran'
The 'tran' keyword is used in dump tran master with no_log
It would be helpful if anyone help me overcome this issue.
You're getting a syntax error because TRAN isn't a SQL keyword and isn't valid for the syntax of DUMP. See https://technet.microsoft.com/en-us/library/ms187315(v=sql.90).aspx. To use DUMP properly, it's either DUMP DATABASE or DUMP TRANSACTION
Note that per the above link, DUMP is flagged as deprecated and only exists for backwards compatibility. It will go away in the future. You should be using BACKUP (probably BACKUP LOG in this case) instead.
From some SQL Server 2005 documentation on DUMP, I found the following:
The DUMP statement is included for backward compatibility. This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Instead, use BACKUP.
I bet that DUMP has already been removed from SQL Server 2014.
System stored procedures such as sp_displayroles, sp_helpdevice, amongst many others, are returning nothing. When I run sp_helpdevice;, all I get as a return value is a string 'sp_helpdevice'. Any idea how to check what's wrong?
I would like to see what devices are present so I may run ALTER DATABASE <database> LOG ON <device>= '20m'; to allow for larger transaction logs.
Edit:
I have the proper permission with sa_role.
I have resolved the problem. I was running the queries via Oracle SQL Developer. It was giving problems probably due to the SQL developer's Sybase DB driver not being very compatible with ASE v16. After using the native ISQL, I can see the results formatted properly.
We have got a large number of long running SQL queries and would like to be able to cancel the execution. So far, I am using an ExecutorCompletionService to run the queries, which works well for cancelling queries which are not yet run.
My problem is: I would like to hard-cancel the currently running queries too. The method java.sql.Statement.cancel() does not seem to work with HSQLDB. From the java doc: "Cancels this Statement object if both the DBMS and driver support aborting an SQL statement." I guess that HSQLDB does not support cancellation.
Does anyone have any idea how to cancel the statement anyways (in a possibly ugly, but still acceptable way)?
See https://sourceforge.net/p/hsqldb/bugs/1436/ for a working solution.
The short variant:
Use the newest SVN Version of HSQLDB or the 2.3.4 Final for the Server.
If the current query that you want to cancel is using a hsqldb connection, create a new connection with admin rights to the same server.
Use
select * from information_schema.system_sessions
to find the session with the statement you are looking for.
Use
ALTER SESSION <SESSIONNUMBER> RELEASE
to cancel the Statement.
Close the Connection.
For me the working sql command was ALTER SESSION <SESSIONNUMBER> END STATEMENT
Occasionally I need to write queries accessing tables in both an MS Access database and an Oracle database. This can be done in MS Access, but Access limits the SQL I can use and has weird syntax.
The BRIDGE command in SQL Developer sounds perfect for this, but I'm having trouble getting it to work. When trying to execute this:
BRIDGE FallEnrollment2012 AS CentralServer(SELECT * FROM "Fall 2012 Enrollment 10-24-12")
SELECT * FROM FallEnrollment2012 WHERE ROWNUM <=10
I get this error message:
ORA-00900: invalid SQL statement
00900. 00000 - "invalid SQL statement"
*Cause:
*Action:
Between BRIDGE and FallEnrollment2012 a syntax error is indicated, but I can't figure out what the issue is. As far as I can tell from the examples I've looked at, it's correct as written. Can anyone tell me what I'm doing wrong?
This is a bug in SQL Developer 4.0 Beta1 & Beta2.
The workaround is to start SQL Developer , Tools > Migration > Scratch Editor .Then open the worksheet and run your BRIDGE command.
In this way the migration plugin is loaded which provides the BRIDGE functionality.
A fix is being worked on
Regards,
Dermot.
I am trying to use a WITH clause in Oracle, but it is not returning any data.
This is the query I am trying to run...
with test as
(select count(*)
from my_table)
select *
from test;
When I run this code, I get back the count of the records in my_table
select count(*)
from my_table
I am on Oracle 10g so the query should work...
select * from v$version;
yields
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Solaris: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
Could it a permissions issue or something?
*EDIT: *
I believe my question is clear. Using the WITH statement will not return any records for me, even though the "select count(*) from my_table" statement inside the WITH statement works correctly, which would lead me to believe that there is another issue that I am unable to figure out, hence this question :)
EDIT 2
OK, so if I try and execute the query from a linked server from SQL server management studio I get some error information back:
sg 7357, Level 16, State 2, Line 1
Cannot process the object "with test as
(select count(*)
from v$version)
select * from test;". The OLE DB provider "MSDAORA" for linked server "MyServer" indicates that either the object has no columns or the current user does not have permissions on that object.
Maybe the optimizer is materializing the count query (dumb, I agree). It's a shot in the dark but do you have these privileges?
grant query rewrite to youruser;
grant create materialized view to youruser;
Try giving the aggregate an alias name.
with test as
(select count(*) as MyCount
from my_table)
select MyCount
from test;
The following worked just fine for me (10gR2)
SQL> with test as
2 (select count(*)
3 from user_tables)
4 select *
5 from test;
COUNT(*)
----------
593
SQL>
What client are you using?
This question is confusing. Are you saying you are or are not getting back the count from my_table?
You should be getting back the count because that's exactly what you asked for in the with clause.
It's analogous to writing:
select *
from (select count(*) from my_table);
Some people at my company ran into this the other day - we traced it down to the Oracle client version [and thus the OCI.dll] version that was being picked up by PL/SQL developer. Some of our dev PCs had Oracle 8 (!) client installs still knocking around on them as well as more recent versions.
The symptom was that not only were queries written using a WITH clause returning no rows, they were returning no columns either! If you manually set the app to pick up the Oracle 11 oci.dll then it all worked.
I think what is going on is that Oracle 8 predates the WITH clause (introduced in Oracle 9, and enhanced subsequently). Now, mostly you can get different versions of the Oracle client and server to talk to one another. However because the client has a certain amount of 'intelligence', it is supposed to be semi-aware of what sort of operation it is submitting to the database, and so does some form of primitive parse of the SQL. As it doesn't recognize the command as a SELECT, it treats it as some unknown command [e.g. possibly a DDL command] and doesn't recognize it as returning a resultset. If you turn on SQL_TRACE for the session you can see the SQL gets PARSEd and EXECUTEd fine on the server, but that no calls to FETCH are made.
I had a similar thing myself recently when trying to use the new WITH syntax in Oracle 12 that allows an inline function definition. If you try simple examples using an Oracle 11 thick client-based application, such as PL/SQL developer or SQL*Plus, then you get an error. If you use an Oracle 12 client, or a thin-client application that doesn't rely a client-side install, then it works.