I have a Oracle view where when trying to view, replace, or even drop the view it shows below error:
DROP X.z force
*
ERROR at line 1:
ORA-06553: PLS-707: unsupported construct or internal error [2604], [403]
ORA-06553: PLS-103: Encountered the symbol "Vendor " when expecting one of
the following:
<an identifier> <a double-quoted delimited-identifier>
ORA-06553: PLS-112: end-of-line in quoted identifier
The column mentioned mistakenly have a break line
(it is: "Vendor
Name"). The problem that I cannot replace, rename or even drop to fix the issue.
Is there any way I can forcedly drop it or recreate ?!
Based on what is described in My Oracle Support Doc ID 2254717.1, which seems to be about exactly this problem, you should be able to do something like:
column object_id new_value bad_object_id;
select object_name, object_type, owner, status, object_id
from all_objects
where object_type='VIEW' and owner='X' and object_name = 'Z';
OBJECT_NAME OBJECT_TYPE OWNER STATUS OBJECT_ID
------------------------------ ------------------- ------------------------------ ------- ----------
Z VIEW X VALID 445264
exec dbms_utility.invalidate(&bad_object_id);
PL/SQL procedure successfully completed.
select object_name, object_type, owner, status, object_id
from all_objects
where object_type='VIEW' and owner='X' and object_name = 'Z';
OBJECT_NAME OBJECT_TYPE OWNER STATUS OBJECT_ID
------------------------------ ------------------- ------------------------------ ------- ----------
Z VIEW X INVALID 445264
drop view X.z;
View X.Z dropped.
I've used substitution variables but you can just manually enter the object ID of course.
I haven't been able to figure out how to recreate the issue - the MoS doc seems to also not know how it happened, though in that case was from an 11g to 12c upgrade, and can only speculate vaguely about corruption. I tried exporting and importing a view using the same versions but it still didn't complain. So I haven't been able to verify this will actually work as advertised, but it looks like it should...
Related
I was working on a trigger, now I want to make some changes and see the code, is it possible to see, if so then how? the trigger is working fine, is there any command in plsql to where I can check out the code? I am using sql command line
user_triggers (or all_triggers) have the trigger source code. Similarly user_source (or all_source) have other source code.
General rule though that I follow is to always always always have a file structure where I keep the source. 100% rule that no one in the team is allowed to violate ever. Then I view the act of creating trigger equivalent to "compiling" in traditional programming. In that model, you would have a directory tree for example
<project>/src
<project>/src/plsql
<project>/src/plsql/<folder for each package>/<files>
<project>/src/plsql/<folder for each table>/<triggers>
And then "modifying" is simply changing them here and "compiling" again (compiling will imply running these via sqlplus - or still better creating a shell script.
In this model, you can easily incorporate several available version control tools as well.
GUI would display it prettier, but SQL*Plus can do it as well. Here's an example:
Creating a sample trigger:
SQL> create or replace trigger trg_update_percentage
2 after update or insert on item
3 for each row
4 begin
5 insert into students_percentage (sid, total_per)
6 select sid, total from student_report
7 where sid = :new.sid;
8 end;
9 /
Trigger created.
Fetch its description from USER_TRIGGERS; as the body is stored into the LONG datatype column, set long should be used (otherwise you won't see the complete code).
SQL> set long 4000
SQL> select trigger_name, trigger_type, triggering_event, table_name, trigger_body
2 from user_Triggers where trigger_name = upper('trg_update_percentage');
TRIGGER_NAME TRIGGER_TYPE TRIGGERING_EVENT TABLE_NAME
------------------------- -------------------- -------------------- ----------
TRIGGER_BODY
--------------------------------------------------------------------------------
TRG_UPDATE_PERCENTAGE AFTER EACH ROW INSERT OR UPDATE ITEM
begin
insert into students_percentage (sid, total_per)
select sid, total from student_report
where sid = :new.sid;
end;
SQL>
While checking v$sql in my database, I came across this query.
select p_obj#, flags, code, audit$ from edition$ where obj#=:1
Can anybody please explain what is this select statement for ?
I think the query is executed while gathering schema statistics by my application. But I cannot understand it.
Oracle actually stores meta data information on base tables(usually followed by $ sign on its name).
Its a base table for edition objects. DBA_EDITIONS is the view created for this base table.
An edition makes it possible to have two or more versions of the same editionable objects in the database.
SQL> select obj# from edition$;
OBJ#
----------
133
SQL> select object_type, object_name from all_objects where object_id=133;
OBJECT_TYPE OBJECT_NAME
---------------- -------------------
EDITION ORA$BASE
I'm writing a custom program to dump the database metadata to files in order to manage them with version control. The default way that data pump or export works isn't ideal for a few reasons (eg. I'd like a separate directory per table).
Sql Developer provides a number of ways of creating export scripts for any object. One way is just by right-clicking the object and selecting Quick DDL. By viewing the logs it creates, one can see the actual SQL it issues to create the DDL script. I've used these scripts to write my custom program and for the most part, they've been perfect.
When I generate the DDL for a materialized view, the SQL it generates is:
SELECT DBMS_METADATA.GET_DDL('MATERIALIZED_VIEW',:name,:owner) FROM DUAL
UNION ALL
SELECT DBMS_METADATA.GET_DEPENDENT_DDL('INDEX',TABLE_NAME, TABLE_OWNER) FROM (
SELECT table_name, table_owner FROM all_indexes
WHERE table_owner = :owner AND table_name = :name
AND index_name NOT IN (
SELECT constraint_name FROM sys.all_constraints
WHERE table_name = table_name AND constraint_type = 'P'
) AND ROWNUM = 1
)
UNION ALL
SELECT dbms_metadata.GET_DEPENDENT_DDL ('COMMENT', :name,:owner ) FROM DUAL
For this script, when executed via SQL Developer Quick DDL, it generates the metadata for the materialized view properly. When I run this script in a program (or even manually with SQL Developer itself), it produces the following errors:
ORA-31608: specified object of type COMMENT not found
ORA-06512: at "SYS.DBMS_METADATA", line 5805
ORA-06512: at "SYS.DBMS_METADATA", line 8436
ORA-06512: at line 1
31608. 00000 - "specified object of type %s not found"
*Cause: The specified object was not found in the database.
*Action: Correct the object specification and try the call again.
This particular materialized view doesn't have any comments (obviously), but I would have expected this part of the clause to just return 0 rows instead of generating an error (especially since SQL Developer uses this itself seemingly without errors).
Is there a way I can avoid this error, while still including comments in the metadata if they exist?
This issue exists on both Oracle 10g & 11g databases.
I was not able to test as I don't really know how to create mview without comment... However the below should work for you. Try to query dba_mview_comments instead of dual to not execute the function when you don't have comments.
UNION ALL
SELECT dbms_metadata.get_dependent_ddl ('COMMENT', :name, :owner)
FROM dba_mview_comments mvc
WHERE mvc.mview_name = :name AND
mvc.owner = :owner AND
length(comments) > 0 AND
rownum = 1
I am using Sql Developer to access a oracle database. Recently I created a View with the option NOFORCE CREATE OR REPLACE NOFORCE VIEW XXXX (...)
Afterwards I looked into the definition of the newly created view and I got a statement looking like CREATE OR REPLACE FORCE VIEW "name"."XXXX"
Now I am not quite sure, if this is a wrong display setting for the Sql Developer or if the view is created with the force.
This just appears to be how Oracle handles views once they've been created, as you can see from the following example:
create or replace noforce view dummy_vw as select dummy from dual;
select * from user_views where view_name = 'DUMMY_VW';
VIEW_NAME TEXT_LENGTH TEXT TYPE_TEXT_LENGTH TYPE_TEXT OID_TEXT_LENGTH OID_TEXT VIEW_TYPE_OWNER VIEW_TYPE SUPERVIEW_NAME EDITIONING_VIEW READ_ONLY
--------- ----------- ---------------------- ---------------- --------- --------------- -------- --------------- --------- ------------------------------ --------------- ---------
DUMMY_VW 22 select dummy from dual N N
select DBMS_METADATA.GET_DDL('VIEW','DUMMY_VW') from DUAL;
CREATE OR REPLACE FORCE VIEW "SCHEMA"."DUMMY_VW" ("DUMMY") AS
select dummy from dual;
Since force/noforce only affects the view at the point when it's created, it doesn't really matter if the script is returned with or without the FORCE keyword, so I guess they just defaulted it to show with the FORCE keyword, since the view exists (if the view script had errors and NOFORCE was used, the view wouldn't have been created).
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.