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.
Related
While running an informatica mapping in v10.4 I'm getting the following error.
The mapping essentially calls a complex stored procedure in Oracle to "swap out" a temporary file to a partitioned fact table.
CMN_1022 [
ORA-20014: FINISH_SP: ORA-20010: Duplicate Indexes: ORA-12801: error signaled in parallel query server P00I
ORA-06512: at "DIMDW.FACT_EXCHANGE_PARTITION_PKG", line 1650
ORA-20010: Duplicate Indexes: ORA-12801: error signaled in parallel query server P00I
ORA-06512: at "DIMDW.FACT_EXCHANGE_PARTITION_PKG", line 1292
ORA-12801: error signaled in parallel query server P00I
ORA-28604: table too fragmented to build bitmap index (172073921,57,56)
ORA-06512: at "DIMDW.FACT_EXCHANGE_PARTITION_PKG", line 1277
ORA-06512: at "DIMDW.FACT_EXCHANGE_PARTITION_PKG", line 1277
ORA-06512: at "DIMDW.FACT_EXCHANGE_PARTITION_PKG", line 1593
I do not know what this error means to Informatica.
Can anyone help me decipher it SPECIFIC TO INFORMATICA
The problem is specific to Oracle, so not sure how to make the answer specific to Informatica, especially without being able to see the details of what the workflow is trying to do.
The ORA-20014: FINISH_SP: ORA-20010: Duplicate Indexes: error is a custom message from the application code. The real key appears to be here: "ORA-28604: table too fragmented to build bitmap index (172073921,57,56)"
It looks like Informatica is attempting to build an index - indirectly through the DIMDW.FACT_EXCHANGE_PARTITION_PKG package - and the process is throwing an error. A simple Google search on ORA-28604 yields the following:
ORA-28604: table too fragmented to build bitmap index (%s,%s,%s)
*Cause: The table has one or more blocks that exceed the maximum number
of rows expected when creating a bitmap index. This is probably
due to deleted rows. The values in the message are:
(data block address, slot number found, maximum slot allowed)
*Action: Defragment the table or block(s). Use the values in the message
to determine the FIRST block affected. (There may be others).
Since this involves the physical fragmentation of the data in the Oracle database, you will almost certainly need to get the DBA involved to troubleshoot this further. Your Informatica workflow likely isn't going anywhere until this is corrected in the database.
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!!
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.
In my new project, I am connecting to HP vertica using DBeaver. I have created a view on a large database (about few billion records) with size limit of 300. This view was created to setup other systems in the pipeline. After everything is setup, I want to remove the size limitation of 300 from the view and want to return all the data. Unfortunately, I can only find that command 'ALTER VIEW' for HP Vertica is allowed to simply rename the view and not modify the view itself. I am forced to drop the view and create another one but this breaks the already established data connection from other systems (Tableau) to the original view.
https://my.vertica.com/docs/7.1.x/HTML/Content/Authoring/SQLReferenceManual/Statements/CREATEVIEW.htm
and
https://my.vertica.com/docs/7.1.x/HTML/Content/Authoring/SQLReferenceManual/Statements/ALTERVIEW.htm
I tried using ALTER VIEW command as in SQL but I get an error -
SQL Error [4856] [42601]:
[Vertica][VJDBC](4856) ERROR: Syntax error at or near "AS"
[Vertica][VJDBC](4856) ERROR: Syntax error at or near "AS"
com.vertica.util.ServerException:
[Vertica][VJDBC](4856) ERROR: Syntax error at or near "AS"
CREATE OR REPLACE VIEW etc etc.
https://my.vertica.com/docs/7.1.x/HTML/Content/Authoring/SQLReferenceManual/Statements/CREATEVIEW.htm
I currently work at migrating an Oracle 9i database (*.dmp file) to an Oracle 11g one.
To achieve this I use the exp and imp Oracle utilities command lines:
exp USERID=<user>/<password>#<database> FILE=<path> OWNER=<owner>
Then I create a skeleton.sql file which will create tables, index tables and finally indexes.
imp <user>/<password>#<database> FILE=<path> INDEXFILE="<path>\skeleton.sql" FROMUSER=<fromuser> TOUSER=<touser>
During this migration I am able to import most of the data correctly, and of course tablespaces are kept the same from one database to the other to avoid any conflicts.
But here comes the problem. In Oracle 11g, KOREAN_LEXER is no longer supported, instead you have to use the KOREAN_MORPH_LEXER. To do so I execute the following SQL commands:
call ctx_ddl.create_preference('korean_lexer','korean_morph_lexer');
call ctx_ddl.add_sub_lexer('global_lexer','korean','korean_lexer',null);
Then I import the skeleton.sql file in order to inject the data needed before the import:
sqlplus <user>/<password>#<database> #<path>\skeleton.sql
The creation of tables and index tables go smoothly until I get the following error for each of the 150+ indexes I created:
CREATE INDEX "<schema>"."WORKORDER_NDX16" ON "WORKORDER"
ERROR at line 1 :
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-20000: Oracle Text error:
DRG-10502: WORKORDER_NDX16 index does not exist
DRG-13201: KOREAN_LEXER is no longer supported
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 366
Indexes are still created, this message is just a warning.
I try to rebuild any of the broken indexes:
ALTER index WORKORDER_NDX16 REBUILD;
Which give me the following error again:
SQL Error : ORA-29874: warning in the execution of ODCIINDEXCREATE routine
ORA-29960: ligne 1,
DRG-10595: failure on ALTER INDEX WORKORDER_NDX16
DRG-50857: oracle error in drixmd.PurgeKGL
ORA-20000: Oracle Text error:
DRG-13201: KOREAN_LEXER is no longer supported
ORA-30576: ConText Option dictionary loading error
DRG-50610: internal error: kglpurge []
29874. 00000 - "warning in the execution of ODCIINDEXALTER routine"
*Cause: A waring was returned from the ODCIIndexAlter routine.
*Action: Check to see if the routine has been coded correctly
Check the user defined warning log tables for greater details.
In my skeleton.sql file, under the creation of each indexes, I have the following lines for each language:
ctxsys.driimp.set_object('LEXER','MULTI_LEXER',12);
...
ctxsys.driimp.set_sub_value('SUB_LEXER','8', NULL, NULL,'KO:KOREAN_LEXER:');
...
So far I am lost on what to do, this seems to be a simple issue to solve but my dba skills are too low to do this on my own.
If anyone could help me on this I would greatly appreciate it !
Thank you.
This looks like your database is using Oracle Text indexes, which are not the same as ordinary indexes. Have you followed completely Oracle Note 300172.1 (Obsolescence of KOREAN_LEXER Lexer Type)? It mentions this code below, which could help.
ALTER INDEX <[schema.]index> REBUILD
PARAMETERS('REPLACE LEXER ko_morph_lexer [MEMORY <size>]');
If all else fails, maybe consider trying to migrate your data into an Oracle 10g database and complete the korean_morph_lexer in 10g. If that works, it would be an easy Data Pump task to move it from 10g to 11g (or 12c).