I'm preparing my new Oracle 11g install for "Direct" SQL*Loader operation. As per the documentation here:
http://docs.oracle.com/cd/B28359_01/server.111/b28319/ldr_modes.htm#i1007669
To prepare the database for direct path loads, you must run the setup script, catldr.sql, to create the necessary views. You need only run this script once for each database you plan to do direct loads to.
So I execute the following sql script:
$ORACLE_HOME/rdbms/admin/catldr.sql
Problem is, when I run this script I get multiple errors. E.g. (and there are a lot more than this, stuff about circular synonyms too):
grant select on gv_$loadistat to public
*
ERROR at line 1:
ORA-04063: view "SUKLTI.GV_$LOADISTAT" has errors
create or replace view v_$loadpstat as select * from v$loadpstat
*
ERROR at line 1:
ORA-01731: circular view definition encountered
Synonym created.
grant select on v_$loadpstat to public
*
ERROR at line 1:
ORA-04063: view "SUKLTI.V_$LOADPSTAT" has errors
create or replace view v_$loadistat as select * from v$loadistat
*
ERROR at line 1:
ORA-01731: circular view definition encountered
Synonym created.
grant select on v_$loadistat to public
*
ERROR at line 1:
ORA-04063: view "SUKLTI.V_$LOADISTAT" has errors
from x$kzsro
*
ERROR at line 15:
ORA-00942: table or view does not exist
And then when I try to run SQL*Loader with "direct=true" I receive the following errors:
ORA-26014: unexpected error on column SYS_NTEOzTt73hE9LgU+XYHax0tQ==.DUMMYCOL NAME
while retrieving virtual column status
ORA-01775: looping chain of synonyms
Note this was a clean Oracle install with some XML schema registered(8) and tables generated off the back of the schema.
Any ideas?
The catldr.sql script says:
Rem NAME
Rem catldr.sql
Rem FUNCTION
Rem Views for the direct path of the loader
Rem NOTES
Rem This script must be run while connected as SYS or INTERNAL.
From the error messages you seem to have run it as your normal user, SUKLTI, rather than as SYS. The documentation you linked to also stated it should be run once per database - not once per end-user.
It should have been run during database creation anyway, via the catalog.sql script, so I'm surprised you need to run it manually at all; and some of the errors suggest the objects it creates did already exist. Through re-running it as SYS doesn't really look like it should hurt.
You can see which objects have been created by querying:
select object_type, object_name
from all_objects
where created > time_just_before_you_ran_the_script
You may need to cross-reference public synonyms with the all_synonyms view to check the table owner, and drop any objects it created from the SUKLTI schema as well as those new public synonyms. (But don't drop anything from the SYS schema...)
You may then need to re-run catldr.sql as SYS to recreate those synonyms pointing to the correct SYS objects.
#AlexPoole
You are completely correct. The script had to be run as SYS.
As this was a "test db" we tore it down and ran the script as SYS at DB re-creation time.
Everything now working!
thanks for reply
Related
community! This is my first question, please go easy on me! :)
I have an ETL process on PDI to orchestrate calls on procedures stored in a package in Oracle.
Some procedures are ready and run normally on PL/SQL Developer.
When I call them using pentaho, either using the job 'SQL' or the transformations 'Execute SQL Script' or 'Call DB procedure' I always get an error related to "can't find the procedure", like: "ORA-00904: "PKG_CARGA_DIARIA_SABARA"."FUN_HELLO_WORLD": invalid identifier" or "ORA-06550: line 1, column 13:
PLS-00201: identifier 'PKG_CARGA_DIARIA_SABARA.FUN_HELLO_WORLD' must be declared".
Please, what am I doing wrong?
enter image description here
enter image description here
enter image description here
EDIT 1: I'm using the user that created the package both to test it in PL/SQL Developer and to connect to the database in PDI.
If I run your code, I get - no surprise - the same message:
SQL> select "PKG_CARGA_DIARIA_SABARA"."FUN_HELLO_WORLD" from dual;
select "PKG_CARGA_DIARIA_SABARA"."FUN_HELLO_WORLD" from dual
*
ERROR at line 1:
ORA-00904: "PKG_CARGA_DIARIA_SABARA"."FUN_HELLO_WORLD": invalid identifier
SQL>
It means that function in that package (which means the package itself) isn't accessible to me. Of course it isn't, I don't have it in my schema. Looks like you don't have it either.
Saying that it works in PL/SQL Developer, I suppose you're connected as package's owner. If user - who tries to call that function - connected to the database in PDI (whatever it is, I don't know/use it) isn't the same as the one you used in PL/SQL Developer and it wasn't granted EXECUTE privilege on the package, then it can't "see" nor execute it.
Therefore:
try to connect as package's owner
if you must connect as someone else, let owner grant EXECUTE privilege, while you should (in PDI) precede package name with the owner name
Found it here! Will post so that anyone can use the answer.
PDI Doesn't automatically consider the schema from the database connection user, you have to specifically add it to your code inside the SQL job.
So: "BEGIN .<procedure name; END;" yelds the error, even though I was running with the procedure and package owner.
And: "BEGIN ..<procedure name; END;" will work it out just fine.
Hope it helps someone, tks!
I want to create a trigger but it is tainted by a warning: trigger created with compilation errors. The query that I am running is:
CREATE OR REPLACE TRIGGER Audit_Salaries
AFTER UPDATE ON EMPLOYEES
FOR EACH ROW
BEGIN
IF (:NEW.Salary > :OLD.Salary*1.20) THEN
INSERT INTO Salary_Audit (EmployeeID, OldSalary, NewSalary,Username, ChangeDate)
VALUES (:NEW.employee_id, :OLD.Salary,:NEW.Salary, user, sysdate);
END IF;
END;
/
Warning: Trigger created with compilation errors.
And this is the result that I am getting:
Warning: Trigger created with compilation errors.
I tried reading other similar answers but the solutions that are given there already exist in mine(syntax).
Due to this, when I log into the different user and run the query, it says the trigger is at fault or not created properly, re-validation failed.
I expect the trigger to be created without any compilation errors along with the understanding of what is wrong in my query.
To see the details of the compilation error, you can query system view USER_ERRORS (or DBA_ERRORS):
SELECT * FROM USER_ERRORS WHERE NAME = 'AUDIT_SALARIES';
I cannot reproduce the error that you are getting, your code compiles successfully when I run it on 11gR2 and 18c. I can only imagine that there is an error in the column names of source table employees or target table salary_audit.
Demo on DB Fiddle
You can see the compilation error using DBA_ERRORS.
SELECT * FROM DBA_ERRORS WHERE NAME = 'AUDIT_SALARIES';
You tagged SQL Developer.
Are you using SQL Developer?
Because if you are...
We automatically do a 'show errors' for you on a compile when errors/warnings are returned. You can also see the compiler messages on the 'Compiler' tab - this should open automatically when you run it.
If you're not seeing this, I'm guessing you're on some version of SQL Developer where a bug is preventing that from happening, but I'm not aware of a version where that would be true.
Try this it will solve you query:
SELECT * FROM DBA_ERRORS WHERE NAME = 'AUDIT_SALARIES'
OR
SELECT * FROM USER_ERRORS WHERE NAME = 'AUDIT_SALARIES';
I am exporting with expdp a schema from a database and the process finishes with no error but when I try to use impdp to import the schema, several views fail to be imported with the following message:
ORA-39083: Object type VIEW failed to create with error:
ORA-00928: missing SELECT keyword
Failing sql is:
CREATE FORCE VIEW...
The create statement that is in the message effectively is missing the SELECT statement, because is truncated way before it should appear. When I check the VIEW in the source database the view is properly created.
The only possible cause I can see for this issue is the length of the statement given that all failing statements have between 389 characters and 404 characters at the point where the statements are truncated.
Is there a way to set the maximum number of characters that the expdp should be able to handle? Or is there a different way I which I should handle these views.
I have problems with some Oracle external table
create table myExternalTable
(field1, field2....)
ORGANIZATION EXTERNAL
(TYPE ORACLE_LOADER
DEFAULT DIRECTORY myDirectory
ACCESS PARAMETERS
(RECORDS DELIMITED BY NEWLINE
NOLOGFILE
NOBADFILE
NODISCARDFILE
FIELDS TERMINATED BY '$')
LOCATION ('data.dsv'));
commit;
alter table myExternalTable reject limit unlimited; --solve reject limit reached problem
select * from myExternalTable;
When I select on the table I have this error :
ERROR at line 1:
ORA-29913: error in executing ODCIEXTTABLEOPEN callout
ORA-29400: data cartridge error
KUP-04040: file data.dsv in myDirectory not found
It seems that the error description is not right because normally the table is already loaded with data.dsv when created.
Plus data.dsv exists in myDirectory.
What is going on? Can somebody help?
Note :
Instead of the select, this is what I normally do :
merge into myDatabaseTable
using
(select field1, field2,.... from myExternalTable) temp
on (temp.field1= myDatabaseTable.field1)
when matched then update
set myDatabaseTable.field1 = temp.field1,
myDatabaseTable.field2 = temp.field2,
......;
This works good on my development environment but on some other environment I have the error I said before :
ERROR at line 1:
ORA-29913: error in executing ODCIEXTTABLEOPEN callout
ORA-29400: data cartridge error
KUP-04040: file data.dsv in myDirectory not found
First I thought that, in the environment it does not work, the directory did not point where it had to but selecting on dba_directories table, I could see the path of the directory is correct.
The problem is related with the access rights of the user on the operating system side. It is defined in Oracle Support Note Create Database Directory on Remote Share/Server (Doc ID 739772.1)
For my case, I created the directory with a sysdba and then for allowing other users to accesss that external table, I created another table which is creates by Create Table as Select statement for the external table. Otherwise, I need to map the Windows Oracle Service owner user to the exact Oracle user which is already defined in the note.
So, it is more like a well fitting workaround for my case.
To sum up the steps in a nutshell:
1- Create the external table T2
2- Create a table named T1 with CTAS to external table
3- Give SELECT right to T1
Hope this helps for your case.
Using SQLDeveloper 4.0.1.14 to create an export script (separate files & "drops" checked), it generated me those 4 lines among others in DROP.sql:
DROP SYNONYM "PUBLIC"."DUAL";
DROP SYNONYM "PUBLIC"."DBMS_SQL";
DROP SYNONYM "PUBLIC"."DBMS_LOCK";
DROP SYNONYM "PUBLIC"."DBMS_OUTPUT";
Now that I have accidentally passed the whole script using SYSTEM user, I can no longer do modification (create or drop tables) to the database, I have that error popping:
An error was encountered performing the requested operation:
ORA-00604: error occurred at recursive SQL level 1
ORA-00942: table or view does not exist
00604. 00000 - "error occurred at recursive SQL level %s"
*Cause: An error occurred while processing a recursive SQL statement
(a statement applying to internal dictionary tables).
*Action: If the situation described in the next error on the stack
can be corrected, do so; otherwise contact Oracle Support.
Vendor code 604
The problem is that I'm getting that error event when I try this:
CREATE OR REPLACE PUBLIC SYNONYM "DUAL" FOR "SYS"."DUAL";
I precise that the SYS.DUAL table still exists as SELECT 1 FROM SYS.DUAL works but SELECT 1 FROM DUAL fails with ORA-00942: table or view does not exist.
I tried to recreate the synonym as SYSTEM and SYSDBA with the same failure.
Can I recreate those synonyms with another way?
Try it as SYS but without the doauble quotes, i.e.:
CREATE OR REPLACE PUBLIC SYNONYM DUAL FOR SYS.DUAL;
not
CREATE OR REPLACE PUBLIC SYNONYM "DUAL" FOR "SYS"."DUAL";
As I understand it the double quotes make the object name case sensitive.
Update - If you have access to metalink then you will find the answer in note 973260.1, something aboput a trigger firing :
ALTER SYSTEM SET "_SYSTEM_TRIG_ENABLED"=FALSE SCOPE=MEMORY;
CREATE OR REPLACE PUBLIC SYNONYM DUAL FOR SYS.DUAL;
ALTER SYSTEM SET "_SYSTEM_TRIG_ENABLED"=true SCOPE=MEMORY;
The note suggest that if this doesnt work, query DBA_TRIGGERS to find a BEFORE CREATE trigger enabled, and if found disable it and then re-issue create synonym statement, then re-enable the trigger.