I am using oracle sql developer client on windows to connect to Oracle Database.
One regular day I got an email that my computer using SQL developer, has deleted ~400 rows from table with ~700 rows (not all of them).
Naturally I started investigating how and why this happened.
I examined all of the queries executed from my client (SQL History) and NONE of them (I am 100% sure about this) deletes anything from the table.
Also there are no triggers or any foreign keys related to this.
In the server logs we say the exact queries and they where one for each row, also they where very specific (obviously generated), the only way for this to happen is to manually delete row from the UI of the client. All 400+ queries were executed in the same second.
But to do so you need to go to the table select 400 rows and click delete.
I always use SQL queries to do things and never would have used the client to delete rows (atleast knowingly).
Other thing is if I somehow deleted the rows through the client I would have deleted all of them or one of them not a specific number of rows.
My question did someone had similar experience?
Can anyone guess how could you delete specific rows with some king of shortcut or something like that?
Thanks.
Related
I’ve been tasked with doing some housekeeping on an Oracle schema I have access to. In a nutshell, I’d like to drop any tables that have not been ‘used’ in the last 3 months (tables that haven’t been queried or had data manipulated in the last 3 months). I have read/write access to the schema but I’m not a DBA; I run relatively basic DML/DDL queries in Oracle.
I’m trying to figure out if there’s a way for me to identify old/redundant tables; here’s what I’ve tried (mostly unsuccessfully)
USER_TABLES was my first port of call, but the LAST_ANALYZED date in this table doesn’t seem to be the last modified/queried date I’m looking for
Googling has brought DBA_Hist tables to my attention, I’ve tried querying some of these (i.e. DBA_HIST_SYSSTAT) but I’m confronted with (ORA-00942: table or view does not exist)
I’ve also tried querying V$SESSION_WAIT, V$ACTIVE_SESSION_HISTORY and V$SEGMENT_STATISTICS, but I get the same ORA-00942 error
I’d be grateful for any advice about whether the options above actually offer the sort of information I need about tables, and if so what I can do to work around the errors I’m getting. Alternatively, are there any other options that I could explore?
Probably the easiest thing to do, to be 100% sure, is to enable auditing on the Oracle tables that you're interested in (possibly all of them). Once enabled, Oracle has an audit table (dba_audit_trail) that you can query to find if the table(s) have been accessed. You can enable auditing by issuing: AUDIT on . BY SESSION;
I chose "by session" so that you only get a single record per session, no matter how many times the session performs the operation (to minimize the records in the audit table).
Example:
audit select on bob.inventory by session;
Then you can query the dba_audit_trail after some time passes to see if any records show up for that table.
You can disable auditing by issuing the "noaudit" command.
Hope that helps.
-Jim
I have a pretty complex query where we make use of a temporary table (this is in Oracle running on AWS RDS service).
INSERT INTO TMPTABLE (inserts about 25.000 rows in no time)
SELECT FROM X JOIN TMPTABLE (joins with temp table also in no time)
DELETE FROM TMPTABLE (takes no time in a copy of the production database, up to 10 minutes in the production database)
If I change the delete to a truncate it is as fast as in development.
So this change I will of course deploy. But I would like to understand why this occurs. AWS team has been quite helpful but they are a bit biased on AWS and like to tell me that my 3000 USD a month database server is not fast enough (I don't think so). I am not that fluent in Oracle administration but I have understood that if the redo logs are constantly filled, this can cause issues. I have increased the size quite substantially, but then again, this doesn't really add up.
This is a fairly standard issue when deleting large amounts of data. The delete operation has to modify each and every row individually. Each row gets deleted, added to a transaction log, and is given an LSN.
truncate, on the other hand, skips all that and simply deallocates the data in the table.
You'll find this behavior is consistent across various RDMS solutions. Oracle, MSSQL, PostgreSQL, and MySQL will all have the same issue.
I suggest you use an Oracle Global Temporary table. They are fast, and don't need to be explicitly deleted after the session ends.
For example:
CREATE GLOBAL TEMPORARY TABLE TMP_T
(
ID NUMBER(32)
)
ON COMMIT DELETE ROWS;
See https://docs.oracle.com/cd/B28359_01/server.111/b28310/tables003.htm#ADMIN11633
I have a very simple table that has an ID (generated by a sequence), and a NAME. I inserted a couple rows which got cached but after a while I wanted to remove them because I wanted to redo my table so I issued a couple of DELETE statements to remove all records (I don't have the privileges to do a TRUNCATE).
After deleting the old rows, I again inserted a couple other records but I didn't bother resetting the sequence.
On PHP, when I SELECT everything on that table, I still get those old deleted rows. But on PL/SQL when I SELECT on that table, it only shows me the new records.
Is the problematic cache on the PHP or Oracle side? If it's on the Oracle side, how do I clear it out?
Thanks!
Recently, a very strange scenario has been reported from one of of our sites.
Based on our fields, we found that there should be some kind of delete that must have happenend for that scenario
In our application code, there is no delete for that table itself. So we checked in gv$sqlarea(since we use RAC) table whether there are any delete sql for this table. We found nothing.
Then we tried to do the same kind of delete through our PL/SQL Developer. We are able to track all delete through gv$sqlarea or gv$session. But when we use below query, lock, edit and commit in plsql developer, there is no trace
select t.*, t.rowid
from <table>
Something which we are able to find is sys.mon_mods$ has the count of deletes. But it is not stored for a long time, so that we can trace by timestamp
Can anyone help me out to track this down
Oracle Version: 11.1.0.7.0
Type : RAC (5 instances)
gv$sqlarea just shows the SQL statements that are in the shared pool. If the statement is only executed once, depending on how large the shared pool and how many distinct SQL statements are executed, a statement might not be in the shared pool very long. I certainly wouldn't expect that a one-time statement would still be in the shared pool of a reasonably active system after a couple hours.
Assuming that you didn't enable auditing and that you don't have triggers that record deletes, is the system in ARCHIVELOG mode? Do you have the archived logs from the point in time where the row was deleted? If so, you could potentially use LogMiner to look through the archived logs to find the statement in question.
visual studion 2008
oracle db 11.1.0.7
oracle client for .NET
I have a relatively simple query, that selects the rows from across multiple tables (up to 4) using joins. OracleDataAdapter returns no rows for the only dataset's table, but if I copy and paste that query in SQLDeveloper then I get the desired results.
I can get the data from other tables using the adapter with no problem, but it seems like it struggles with the bit longer selection query (string length is ~ 300 (not that much at all))
Connection string for the connection is 100% correct.
Any ideas? thank you...
Check that you using same oracle user to connect to database. Maybe FGAC hides data.
Check that there is no temporary tables in you query.
Solution by OP.
The problem was, that after I imported the data in the SQLDeveloper in one of the involved tables, this change hasn't been committed automatically as I've falsely presumed... I've figured this out after I edited some data in the same table within the SQLDeveloper, and it has failed with the message that the edit operation on uncommitted action is now allowed. The headache I had was in SQLDeveloper, not the DataAdapter.