SQL> flashback table ticket to timestamp TO_TIMESTAMP('13-11-2018 22:30:56',
'dd-mm-yyyy hh24:mi:ss');
flashback table ticket to timestamp TO_TIMESTAMP('13-11-2018 22:30:56',
* 'dd-mm-yyyy hh24:mi:ss')
ERROR at line 1:
ORA-00604 : error occurred at recursive SQL level 1
ORA-01031 : insufficient privileges
P.S. : I already added flashback any table system privilege.
Most probably you have a trigger such as after event type which contains some operations that prevent you perform your command line operations related with them. Try to disable those triggers, and then retry flashback table ...
To detect the obstacle, use :
select owner, trigger_name
from user_triggers -- for current schema, might be replaced with "dba_triggers" for the whole
where trigger_type = 'AFTER EVENT';
Related
I was using yeasterday many times Data Pump in Sql Developer Wizard to export and import data. After each export/import a new master table appeared under the "+" button in sql developer(view->dba).
I wanted to drop all this tables(about 10 tables) and I was successfull for all cases, except 2 of them. When I'm writing sql code: drop table x, it shows me error that this tables doesn't exists. It was working fine for every others tables..
When i run query select * from dba_tables where table_name='x' the table is there. I'm writing drop statement as system user.
select *
from dba_tables
where table_name in ('moj_dump_job'
, 'moj_job_data_pump');
OWNER TABLE_NAME
------------------------------ ------------------------------
SYSTEM moj_dump_job
SYSTEM moj_job_data_pump
drop table moj_dump_job;
Error starting at line : 1 in command -
drop table moj_dump_job
Error report -
ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
*Cause:
*Action:
I tired to drop this jobs, but it doesnt't work:
select owner_name, job_name
from DBA_DATAPUMP_JOBS;
OWNER_NAME JOB_NAME
------------------------------ ------------------------------
SYSTEM moj_job_data_pump
SYSTEM moj_dump_job
BEGIN
dbms_scheduler.drop_job(job_name => 'moj_dump_job');
END;
Error starting at line : 13 in command -
BEGIN
dbms_scheduler.drop_job(job_name => 'moj_dump_job');
END;
Error report -
ORA-27475: "SYSTEM.MOJ_DUMP_JOB" must be a job
ORA-06512: at "SYS.DBMS_ISCHED", line 213
ORA-06512: at "SYS.DBMS_SCHEDULER", line 657
ORA-06512: at line 2
27475. 00000 - "unknown %s \"%s\".\"%s\""
*Cause: The specified object did not exist, privileges were not granted,
or the object was of the wrong type.
*Action: Specify an object of the correct type on which you have privileges.
Do you have any idea what can I do? Using schema name before table name doesn't help.
Best regards, Darek
Thank's for your help. It work's.
drop table "moj_dump_job"
drop table "moj_job_data_pump";
Table "moj_dump_job" dropped.
Table "moj_job_data_pump" dropped.
Now
select *
from dba_tables
where table_name in ('moj_dump_job'
, 'moj_job_data_pump');
select owner_name, job_name
from DBA_DATAPUMP_JOBS;
Both statements doesn't return any rows. That's perfect, but the 2 tables are still visible under view ->dba ->data pump -> export jobs. How to drop them from the tree?
The reason it was not working cause by default Oracle changes job name to uppercase. To avoid it need use '"my_job"'
As per Oracle doc
Follow SQL naming rules to name Scheduler objects in the
DBMS_SCHEDULER package. By default, Scheduler object names are
uppercase unless they are surrounded by double quotes. For example,
when creating a job, job_name => 'my_job' is the same as job_name =>
'My_Job' and job_name => 'MY_JOB', but different from job_name =>
'"my_job"'. These naming rules are also followed in those cases where
comma-delimited lists of Scheduler object names are used within the
DBMS_SCHEDULER package.
I've some problem with procedure which select data via dblink
I can select source tables normally and procedure compiles successfully but when I run this procedure I receive error
create or replace procedure proc1 is
begin
execute immediate 'truncate table table1';
INSERT /*+ APPEND NOLOGGING PARALLEL */
INTO table1
SELECT smthng
FROM table1#dblink uo
LEFT JOIN table2#dblink uoc
ON uoc.id = uo.id
LEFT JOIN table3#dblink uos
ON uos.id = uoc.id;
COMMIT;
end;
SQL> execute proc1
begin proc1; end;
ORA-01017: invalid username/password; logon denied
ORA-02063: предшествующий line из dblink
ORA-06512: на "proc1", line 8
ORA-06512: на line 1
Any explanations?
To give a solution on this question you need to know which version of Oracle database you are using, you need to explain us how the database link is being created. Is it a public link ? Is it anonymous ? What is the DOP (degree of parallelisme) specified on ALL tables used in your query. Who is executing the query ? Is it the same user that your are using via a remote database link ? Is this user having the same password as the one executing the query locally ?
I can make it even worse : do you use an ops$-account externally identified ? Or is this last one assigned a password ?
And last but NOT LEAST check via the auditing tables if the users that cannot logon to the remote database. Tell me is this the same user you are using with your local query ?
My scripts use SQL*Plus error logging to track errors during installation.
The scripts start like this - they enable erorr logging and truncate any existing entries:
SQL> set errorlogging on truncate
SQL> select * from table_does_not_exist;
select * from table_does_not_exist
*
ERROR at line 1:
ORA-00942: table or view does not exist
Then at the very end I query sperrorlog to see what went wrong:
SQL> select statement from sperrorlog;
STATEMENT
--------------------------------------------------------------------------------
select * from table_does_not_exist
But every now and then the truncate does not work, and I get errors from previous installations. Why doesn't truncate work?
Despite it's name, SQL*Plus error logging truncate does not actually truncate the table. It deletes the data and does not commit.
This SQL*Plus session enables error logging and creates an error. Another call to enable errorlogging and truncate does clear out the data, but the rollback undoes the truncate.
SQL> set errorlogging on truncate
SQL> select * from table_does_not_exist;
select * from table_does_not_exist
*
ERROR at line 1:
ORA-00942: table or view does not exist
SQL> commit;
Commit complete.
SQL> set errorlogging on truncate
SQL> select statement from sperrorlog;
no rows selected
SQL> rollback;
Rollback complete.
SQL> select statement from sperrorlog;
STATEMENT
--------------------------------------------------------------------------------
select * from table_does_not_exist
SQL>
To be safe, you should always issue a commit right after set errorlogging on truncate.
To be safe, you should always issue a commit right after set errorlogging on truncate
Or, do an explicit TRUNCATE which would do an implicit commit being DDL statement. Of course, this is just like not using the truncate option, however, so is the problem with the rollback. I found the workaround for the rollback issue and shared it in my blog SQL*Plus error logging – workaround for ROLLBACK issue
Coming back to your issue, I am trusting more on an explicit truncate:
SQL> set errorlogging on
SQL> select * from table_does_not_exist;
select * from table_does_not_exist
*
ERROR at line 1:
ORA-00942: table or view does not exist
SQL> select statement from sperrorlog;
STATEMENT
----------------------------------------
select * from table_does_not_exist
SQL> truncate table sperrorlog;
Table truncated.
SQL> select statement from sperrorlog;
no rows selected
SQL> rollback;
Rollback complete.
SQL> select statement from sperrorlog;
no rows selected
SQL>
Alternatively, you could use global temporary table for sperrorlog table and make it on commit delete rows.
I have accdently deleted some rows in a table and did the commit too. Now
I want to recover them.
The DB I'm using is Oracle 11g R2.
I used the following query to get deleted records:
SELECT * FROM MY_TABLE AS OF TIMESTAMP ('13-MAR-11 8:50:58','DD-MON-YY HH24: MI: SS')
But while executing it gives an error saying:
Error at Command Line:3 Column:75
Error report:
SQL Error: ORA-00907: missing right parenthesis
00907. 00000 - "missing right parenthesis"
*Cause:
*Action:
But I couldn't figure the problem in this queury.
Can anyone pls help?
That requires an actual timestamp (or date), you're passing a pair of values.
Try:
SELECT * FROM MY_TABLE
AS OF TIMESTAMP TO_DATE('13-MAR-11 08:50:58','DD-MON-YY HH24:MI:SS')
(Your time format specifier isn't correct either and doesn't match your date string.)
for example :
SELECT * FROM EMP AS OF TIMESTAMP
TO_TIMESTAMP('2005-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')
WHERE name = 'JOHN';
But flashback query may fail with ORA-1555 , other option :
Logminer
if Oracle supplement log is enabled , you can get undo sql for your delete statement
-- switch again logfile to get a minimal redo activity alter system switch logfile;
-- mine the last written archived log
exec dbms_logmnr.add_logfile('archivelog/redologfile', options =>dbms_logmnr.new);
exec dbms_logmnr.start_logmnr(options => dbms_logmnr.dict_from_online_catalog);
select operation, sql_redo from v$logmnr_contents where seg_name = 'EMP';
Oracle PRM-DUL
PRM-DUL will be last option. Even deleted row piece in Oracle block is always just marked row flag with deleted mask, the row piece still can be read via scan Oracle data block . PRM-DUL can scan the whole table , find out every record/row piece marked deleted and write out to flat file.
I have a query like
INSERT INTO sid_rem#dev_db
(sid)
select sid from v$session
Now, when i execute this query i get
ORA-02070: database does not support in this context
This error happens only when I insert data from v$session into some remote db. Its working fine for any other table.
Anyone know why this issue and any workaround for this?
Works using gv$session instead of v$session:
INSERT INTO sid_rem#dev_db(sid)
select sid from gv$session;
gv$ views are global views, that is, they are not restricted to one node(instance), but see the entire database(RAC). v$ views are subviews of gv$.
Searching on the internet I found this has something to do with distributed transactions.
Thread on ora-code.com
Late answer but might still be useful. I've found this error occurs when trying to select from system views across a database link where the system view contains columns of type LONG. If the query can be reworded to avoid the LONG columns these joins will work fine.
Example:
SELECT dc_prod.*
FROM dba_constraints#prod_link dc_prod
INNER JOIN dba_constraints dc_dev
ON (dc_dev.CONSTRAINT_NAME = dc_prod.CONSTRAINT_NAME)
will fail with an ORA-02070 due to accessing the LONG column SEARCH_CONDITION, but
SELECT dc_prod.*
FROM (SELECT OWNER,
CONSTRAINT_NAME,
CONSTRAINT_TYPE,
TABLE_NAME,
-- SEARCH_CONDITION,
R_OWNER,
R_CONSTRAINT_NAME,
DELETE_RULE,
STATUS,
DEFERRABLE,
DEFERRED,
VALIDATED,
GENERATED,
BAD,
RELY,
LAST_CHANGE,
INDEX_OWNER,
INDEX_NAME,
INVALID,
VIEW_RELATED
FROM dba_constraints#prod_link) dc_prod
INNER JOIN (SELECT OWNER,
CONSTRAINT_NAME,
CONSTRAINT_TYPE,
TABLE_NAME,
-- SEARCH_CONDITION,
R_OWNER,
R_CONSTRAINT_NAME,
DELETE_RULE,
STATUS,
DEFERRABLE,
DEFERRED,
VALIDATED,
GENERATED,
BAD,
RELY,
LAST_CHANGE,
INDEX_OWNER,
INDEX_NAME,
INVALID,
VIEW_RELATED
FROM dba_constraints) dc_dev
ON (dc_dev.CONSTRAINT_NAME = dc_prod.CONSTRAINT_NAME)
works fine because the LONG column SEARCH_CONDITION from DBA_CONSTRAINTS is not accessed.
Share and enjoy.
I don't know why this is happening, it's probably in the documentation somewhere but my Oracle-Docs-Fu seems to have deserted me today.
One possible work-around is to use a global temporary table
SQL> create table tmp_ben ( sid number );
Table created.
SQL> connect schema/pw#db2
Connected.
SQL> create table tmp_ben ( sid number );
Table created.
SQL> insert into tmp_ben#db1 select sid from v$session;
insert into tmp_ben#db1 select sid from v$session
*
ERROR at line 1:
ORA-02070: database does not support in this context
SQL> create global temporary table tmp_ben_test ( sid number );
Table created.
SQL> insert into tmp_ben_test select sid from v$session;
73 rows created.
SQL> insert into tmp_ben#db1 select * from tmp_ben_test;
73 rows created.