I am connected to SYSDBA. I want to give access to user 'OFFC' to read and write on directory E:\oracle\extract.So,what I tried is:
CREATE OR REPLACE DIRECTORY EXTRACT_DIR AS 'E:\oracle\extract';
GRANT READ, WRITE ON DIRECTORY EXTRACT_DIR TO OFFC;
GRANT EXECUTE ON UTL_FILE TO OFFC;
What i got as error is:
Directory created.
GRANT READ, WRITE ON DIRECTORY EXTRACT_DIR TO OFFC
Error at line 2
ORA-00604: error occurred at recursive SQL level 1
ORA-12899: value too large for column "OT"."SCHEMA_AUDIT"."OBJECT_CREATED" (actual: 16, maximum: 15)
ORA-06512: at line 2
Why is this error coming when I tried to gave the access?
You must have have created the schema level trigger which keeps log of the newly created object in OT.SCHEMA_AUDIT.
In this table column OBJECT_CREATED stores the schema.object_name and data type of the column is somewhat VARCHAR2(15) or similar.
In your case, you are creating the object OFFC.EXTRACT_DIR (length:16) which is causing the issue.
Either disable the trigger or increase the Length of the OBJECT_CREATED column to around (257)
Cheers!!
Related
I have two Oracle databases using Oracle Standard Edition Two 12.1, DB1 and DB2.
DB1 contains the following table a FILE_TABLE:
ColumnName DataType
File_Id Number
File_Ref Bfile
I am storing Bfile into File_Ref of a FILE_TABLE table.
I want to access the Bfile from FILE_TABLE table and show it in DB2.
I have tried it using the database link. Using database link, I tried to do so:
SELECT FILE_REF FROM FILE_TABLE#dblink;
but it's giving an error: ORA-22992: cannot use LOB locators selected from remote tables
I also tried the DBMS_FILE_TRANSFER but when I researched on it, I got to know that we can only transfer System data files but not Bfile.
Is it true?
This is the syntax I used to transfer file:
DBMS_FILE_TRANSFER.put_file(
source_directory_object => 'db1_dir',
source_file_name => 'db1test.html',
destination_directory_object => 'db2_dir',
destination_file_name => 'db2test.html');
destination_database => 'db1_to_db2',
END;
/
But I was getting an error:
ORA-19505: failed to identify file "/db1_dir/db1test.html"
ORA-27046: file size is not a multiple of logical block size
Additional information: 1
ORA-02063: preceding 3 lines from db1_to_db2
ORA-06512: at "SYS.DBMS_FILE_TRANSFER", line 37
ORA-06512: at "SYS.DBMS_FILE_TRANSFER", line 132
ORA-06512: at line 2
00000 - "failed to identify file \"%s\""
*Cause: call to identify the file returned an error
*Action: check additional messages, and check if the file exists
Is there any way to do it using database link? Are there any other solutions to move a Bfile from one Database to other?
The ora-27046 is generally a sign that during the file transfer the file has been changed. This can be caused by firewalls. Have you verified with that the file is the same.
In addition when you get ora-27046 its not the only error, you get an error stack of several errors. It would be good to post the complete error stack. Also you don't mention which oracle release you are using.
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.
I am getting error while creating procedure and package. Please anyone help me.
My procedure code-
CREATE OR REPLACE PROCEDURE IPROC(CID IN NUMBER, CNAME IN VARCHAR2, CON IN NUMBER, A_NO IN NUMBER, BAL IN NUMBER, TTYPE VARCHAR2)
AS
BEGIN
INSERT INTO CUSTOMER_TBL VALUES(CID,CNAME,CON,A_NO,BAL,TTYPE);
END;
Error-
Error report -
ORA-00604: error occurred at recursive SQL level 1
ORA-01653: unable to extend table SYS.PLSCOPE_ACTION$ by 128 in tablespace SYSAUX
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.
If you're experiencing this error only in Sql Developer, try to change, Tools > Preferences > Database > PL/SQL Compiler, the option PLSCope to None.
PLSCOPE_SETTINGS controls the compile time collection, cross reference, and storage of PL/SQL source code identifier data.
NONE: Disables collection of identifier data.
ALL: Enables the collection of all source code identifier data. This is the default in SqlDeveloper.
SqlDeveloper default for PLScope is All, and maybe is causing this error.
You have no space left in tablespace SYSAUX
Either you also have no space left or your HDD or max limits of SYSAUX are reached.
Also look at script mentioned in https://dba.stackexchange.com/questions/33645/sysaux-tablespace-is-98, maybe it will help you.
If you have acces to the dba_data_files table , This query will show you how much space you have and how much you have utilized.
If it is full add another file to the tablespace or ask dba to add another file to it.
SQL> select file_name, sum(bytes)/1024/1024/1024 "current_gb",sum(maxbytes)/1024/1024/1024 "total_gb" from dba_data_files where tablespace_name='SYSAUX' group by file_name;
FILE_NAME current_gb total_gb
------------------------------------------------------------ ---------- ----------
C:\AKS\AKDB\ORADATA\RESEARCH\SYSAUX01.DBF .546875 31.9999847
To add datafile
Alter tablespace SYSAUX ADD DATAFILE 'C:\AKS\AKDB\ORADATA\RESEARCH\SYSAUX02.DBF' size 100m autoextend of maxsize 2g;
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