IMPDP SQLFILE: constraint_name multibyte characters leads to ORA-00972

Hello

I'm actually constraint_name made of multibyte characters (for example: constrain_name = "VALIDA_CONFIRMAÇÃO_PREÇO13").
Of course this Bad Idea® is hereditary (I'm against all the stuff of fantasy as water in the names of files or directories on my filesystem...)

The scenario is as follows:
0 - I'm supposed to do a 'remap_schema '. Everything in the schema SCOTT should now be in a schema NEW_SCOTT.
1 - the scott schema is exported via datapump
2 - I'm an impdp with SQLFILE to remove all the DDL (table, packages, synonyms, etc...)
3. I do a few sed on the sqlfile generated to replace each occurrence of SCOTT at NEW_SCOTT (this part is OK)
4. once the modified sqlfile is executed, I'm doing an impdp with DATA_ONLY.

(The scenario was envisioned in this thread: {message identifier: = 10628419})

I get a few ORA-00972: identifier is too long to step 4, when you run the sqlfile.
I see that some DDL for creating the constraint in the file (generated in step # 2) is read as follows:
ALTER TABLE "TW_PRI"."B_TRANSC" ADD CONSTRAINT "VALIDA_CONFIRMAÃÃO_PREÃO14" CHECK ...
Of course, the original name of the constraint with the cedilla and the tilde translates to something that is longer than 30 char/byte...

As the original name is the Brazil, I also tried to add an EXPORT LANG = pt_BR. UTF-8 in my script before you run the impdp for sqlfile. It doesn't change anything. (the original $LANG is en_US. UTF-8)

To create a unit test for this thread, I tried to reproduce it on my sandbox database... but, I don't have the issue. :-(

The real system is a database of 4-nodes on Exadata (11.2.0.3) with NLS_CHARACTERSET = AL32UTF8.
My sandbox database is a 11.2.0.1 (nonRAC) on RHEL4 AL32UTF8 also.

The constraint_name argument is the same on the two system: I checked byte by byte using DUMP() on the constraint_name argument.

Feel free to make light and/or seek clarification if necessary.


Thanks in advance for those who will take their time to read all this.
:-)

--------
I decided to register my testcase to my sandbox database, even if it does NOT reproduce the issue + (maybe I'm missing something obvious...) +.

I use the following files.
-createTable.sql:
$ cat createTable.sql 
drop table test purge;

create table test
(id integer,
val varchar2(30));

alter table test add constraint VALIDA_CONFIRMAÇÃO_PREÇO13 check (id<=10000000000);

select constraint_name, lengthb(constraint_name) lb, lengthc(constraint_name) lc, dump(constraint_name) dmp
from user_constraints where table_name='TEST';
-expdpTest.sh:
$ cat expdpTest.sh 
expdp scott/tiger directory=scottdir dumpfile=testNonAscii.dmp tables=test
-impdpTest.sh:
$ cat impdpTest.sh 
impdp scott/tiger directory=scottdir dumpfile=testNonAscii.dmp sqlfile=scottdir:test.sqlfile.sql tables=test
It comes to the race:
[oracle@Nicosa-oel test_nonAsciiColName]$ sqlplus scott/tiger

SQL*Plus: Release 11.2.0.1.0 Production on Tue Feb 12 18:58:27 2013

Copyright (c) 1982, 2009, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> @createTable

Table dropped.


Table created.


Table altered.


CONSTRAINT_NAME                  LB       LC
------------------------------ ---------- ----------
DMP
--------------------------------------------------------------------------------
VALIDA_CONFIRMAÇÃO_PREÇO13             29         26
Typ=1 Len=29: 86,65,76,73,68,65,95,67,79,78,70,73,82,77,65,195,135,195,131,79,95
,80,82,69,195,135,79,49,51


SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@Nicosa-oel test_nonAsciiColName]$ ./expdpTest.sh 

Export: Release 11.2.0.1.0 - Production on Tue Feb 12 19:00:12 2013

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "SCOTT"."SYS_EXPORT_TABLE_01":  scott/******** directory=scottdir dumpfile=testNonAscii.dmp tables=test 
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 0 KB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
. . exported "SCOTT"."TEST"                                  0 KB       0 rows
Master table "SCOTT"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SCOTT.SYS_EXPORT_TABLE_01 is:
  /home/oracle/scott_dir/testNonAscii.dmp
Job "SCOTT"."SYS_EXPORT_TABLE_01" successfully completed at 19:00:22

[oracle@Nicosa-oel test_nonAsciiColName]$ ./impdpTest.sh 

Import: Release 11.2.0.1.0 - Production on Tue Feb 12 19:00:26 2013

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SCOTT"."SYS_SQL_FILE_TABLE_01" successfully loaded/unloaded
Starting "SCOTT"."SYS_SQL_FILE_TABLE_01":  scott/******** directory=scottdir dumpfile=testNonAscii.dmp sqlfile=scottdir:test.sqlfile.sql tables=test 
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Job "SCOTT"."SYS_SQL_FILE_TABLE_01" successfully completed at 19:00:32

[oracle@Nicosa-oel test_nonAsciiColName]$ cat scott_dir/test.sqlfile.sql 
-- CONNECT SCOTT
ALTER SESSION SET EVENTS '10150 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '10904 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '25475 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '10407 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '10851 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '22830 TRACE NAME CONTEXT FOREVER, LEVEL 192 ';
-- new object type path: TABLE_EXPORT/TABLE/TABLE
CREATE TABLE "SCOTT"."TEST" 
   (     "ID" NUMBER(*,0), 
     "VAL" VARCHAR2(30 BYTE)
   ) SEGMENT CREATION DEFERRED 
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 COMPRESS FOR OLTP LOGGING
  TABLESPACE "MYTBSCOMP" ;
 
-- new object type path: TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
ALTER TABLE "SCOTT"."TEST" ADD CONSTRAINT "VALIDA_CONFIRMAÇÃO_PREÇO13" CHECK (id<=10000000000) ENABLE;
I was expecting the cedilla and the tilde characters not displayed correctly...

Published by: Nicosa on February 12, 2013 19:13

Hello
I had some strange effects if I didn't set the translation be utf8 in my ssh client (PuTTY in my case). Is - this somehow something that automatically happens in an environment, but not the other?

In putty, this is the window-> translation and then choose utf8

Also make sure that's not sed plague rather than impdp?

See you soon,.
Harry

Tags: Database

Similar Questions

  • Handling multibyte characters

    Hello

    I created a procedure that sends an e-mail with UTL_SMTP.

    The procedure includes a section in which we add attachments to e-mail.

    Now, the question is when I add an attachment that contains multibyte characters, these characters are replaced by '?'.

    Can anyone provide guidance on this?

    It works fine now.

    First of all, I discovered that if the SMTP server supports the 8BITMIME extension, in my case it was the case

    Then while keeping the same thing, I've converted prior to the given RAW and then used WRITE_RAW_DATA.

  • * ORA-00972: identifier is too long * when drop index table app

    Hello

    I had some difficulties with dropApplicationTableIndex. He raised an exception ORA-00972:
    java.sql.SQLException: ORA-00972: identifier is too long

    at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
    at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
    at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
    at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:745)
    at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:210)
    at oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:961)
    at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1190)
    at oracle.jdbc.driver.OracleStatement.executeUpdateInternal(OracleStatement.java:1657)
    at oracle.jdbc.driver.OracleStatement.executeUpdate(OracleStatement.java:1626)
    at oracle.spatial.rdf.client.jena.Oracle.executeUpdate(Oracle.java:769)
    at oracle.spatial.rdf.client.jena.GraphOracleSem.dropApplicationTableIndex(GraphOracleSem.java:3695)


    However, the longer name of my models is 23 characters, making it the longest name of characters 27A table (+ _TPL).
    Is there a still shorter limit for the length of model name?

    Thank you

    Kind regards
    Julien

    Hi Julien,

    In fact, the limit for a semantic model, created using the Jena adaptor is 19 characters. This is because the application table index uses TRIPLEIDX as a suffix.

    Best,
    Vlad

  • PL/SQL: ORA-00972: identifier is too long.

    Hi all

    I have a question on the Express request form. I have my form fields that must be completed to save information about the database. It works fine until I click on create a button - I get the following error:
    ORA-06550: line 1, column 243: PL/SQL: ORA-00972: identifier is too long ORA-06550: line 1, column 7: PL/SQL: SQL Statement ignored
    
    
    Unable to process row of table FIS_REPAT_WITH_APPLICANT_INFO.
    I checked the length of table name, & he is 28 characters long. What could be the problem with this? Any help is appreciated. Thank you in advance.

    Concerning
    Kamo

    Hi Tom,

    Sorry for the late reply. It turns out that my problem was with date formats: I changed the format of the date of my entire application of MON/DD/YY to YYYY-MM-DD, which worked well. However, on a a date field forms I changed the Capture_Date source to to_char (Capture_Date, 'YYYY-MM-DD') that's why I got the error I got.

    At one point, I got an error message: ORA - 06502:PL / SQL: digital or value error: character string buffer too small
    That's why I started another thread: Re: ORA - 06502:PL / SQL: digital or value error: character string buffer too small

  • ORA-00972: identifier is too long

    Hai all,

    SQL > delete / * parallel nologging * / of DWEvent where EVENTTIME < to_date('2012-02-01','YYYY-MM-DD');

    ERROR:
    ORA-00972: identifier is too long

    No idea why?

    You have a double quote at the end of your statement.
    What happens if you change:

    delete /* nologging parallel */ from DWEvent where EVENTTIME < to_date('2012-02-01','YYYY-MM-DD')";
    {code}
    into:
    {code}
    delete /* nologging parallel */ from DWEvent where EVENTTIME < to_date('2012-02-01','YYYY-MM-DD');
    {code}
    ?
    
    And by the way: your 'hint' is not really a hint, but only a comment.
    Hints start with /*+ YOUR_HINT */, you forgot the + sign.
    
    You can search the syntax easily from http://www.oracle.com/pls/db112/homepage                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        
    
  • ORA-00972 dynamic sql error

    Here is my code... I got THE FOLLOWING ERROR message

    "ORA-00972: identifier is too long.
    ORA-06512: at "VVMS_BATCH. QUEUE_DYNAMIC', line 26
    ORA-06512: at line 2'

    Code:

    create or replace
    procedure sales_dynamic is
    cursor cur_sales is
    Select sales_CATEGORY_ID, sales_ITEM_STATUS, sales_ITEM_KEY, sales_ID from sales_ITEM_HISTORY where sales_ITEM_STATUS = 'OH' and ONHOLD_DT < sysdate;
    / * number of v_err_code;
    v_err_msg varchar2 (64); * /

    type v_source_table is table of the sales_category.source_table%type;
    z_v_source_table v_source_table: = v_source_table();
    long stmt (2000);
    v_ot varchar2 (2);

    Start
    I'm looping cur_sales
    Start
    v_ot: = 'OT ';
    Select to bulk source_table fired into z_v_source_table from ventes_categorie where sales_CATEGORY_ID = i.sales_CATEGORY_ID;

    j in z_v_source_table.first... loop z_v_source_table. Last

    stmt: = 'start' |' update '. z_v_source_table (j) | q '(set sales_ITEM_STATUS = ('OT") where sales_ITEM_KEY = i.sales_ITEM_KEY)';
    immediately execute stmt USING z_v_source_table (j), i.sales_ITEM_KEY;
    dbms_output.put_line ('run' | z_v_source_table (j));
    end loop;
    end;
    end loop;
    end sales_dynamic;
    executing update lois ( set table_id = ('OT') where table_id = i.ey_id)
                                           ^    ^
                                           |    |
                                           |    |
                                           remove this parenthesis
    

    your stmt variable should resemble:

    stmt :='update '|| z_v_source_table(j) ||' set sales_ITEM_STATUS = ''OT'' where sales_ITEM_KEY = i.sales_ITEM_KEY';
    
  • Impdp sqlfile parameter

    Hello

    OPERATING SYSTEM: HP - UX
    Oracle10g

    My production dba team sent me a sqlfile comprising 30K tables. They used sqlfile = parameter to get the DDL of the tables. I need to create the same DDL commands on my dev database.

    My thought is rather than generate the ddl sqlfile orders and recreate all the ddl in the dev environment.
    Why not to use the command to create structures of table below...

    leader lines = abc.dmp user/pwd = n = aabb log patterns exp = abc.log

    Would not be in the above given command creates all the structures of table (DDL)?

    They are right for which one needs the sqlfile parameter take all DDLS and manually create?

    Also pls inform me the importance of the sqlfile parameter in expdp/impdp...


    Thank you
    KSG

    Published by: KSG on March 25, 2010 10:51

    My understanding is... After you run the impdp command, a sqlfile will be generated which contains the dumpfile DDL commands relavent. I'm good with that?

    Yes. It is somewhat similar to show = Yes command in imp

    And I want to run the script to create the DDL...

    Another is my doubt...

    It's a hard way to create all the DDL by using the sql script file?

    Why should I not go and take an export of all the table structure to help

    expdp user/pwd file = dumpfile.dmp lines = n = abc log owner = dumpfile.log

    and just import the dumpfile.dmp... Woundn can't create this all the DDL as long as same as the generation of the sqlfile script?

    It depends on the rquirement. lets see you want to exclude a few tables full dump for the creation of the structure, sqlfile will come handy.
    not sure what all the objects in your dump file are made up and you want to see the content (objects) of the dump file, instead of imporing to the database and check then you will be able to access it without actually importing. You can use lines = n only when you are sure and import the entire structure of the objects.

    Anil Malkai

  • Problem with ore.save () - leads to ORA-00942 table or view does not exist

    I get an error when I try to use ore.save () to register a function of R in a data store. This works in our environment of DEV, but for some reason any is not going back to QA. (No not the right to try Prod...)

    What I see:

    -The function to be saved - loadInputData() - is defined

    -A confirmed that the data store exists

    -Tried to save a simple vector - same question

    -Looked directly into RQSYS. RQ$ DATASTOREOBJECT and it seems that he actually recorded? Except call ore.load () for the same object (function loadInputData) also gives the ORA-00942.

    -Both the function and the simple vector see when I call ore.datastoreSummary (), even if the call to ore.save () for both threw the ORA-00942

    -I am connected to a synonym account

    Full traceback from left to right:

    12 .oci. GetQuery (Conn., instruction, data = data = prefetch prefetch,

    bulk_read = bulk_read)

    11 .local (conn, statement,...)

    10 ROracle::dbGetQuery (.ore.con (), qry,...)

    9 ROracle::dbGetQuery (.ore.con (), qry,...)

    8 ore. QueryEnv$ dbGetQuery (qry, healthy = healthy,...)

    7 OREbase:.ore.dbGetQuery (stmt, data = raw.df)

    6.ore.insertObj (get (nm, envir = envir), name, nm, envAsEmptyenv)

    5 FUN ("loadInputData" [[1 L]],...)

    4 lapply (X = X, FUN = FUN,...)

    3 sapply (existingobj.names, function (nm).ore.insertObj (get (nm,

    ((envir = envir), name, nm, envAsEmptyenv))

    2 ore.save (loadInputData, name is MODEL_SAVE_DATASTORE, overwrite = TRUE)

    Question of privilege. The account was missing rights RQADMIN, as well as CREATING of DATA MINING, UNLIMITED TABLESPACE and maybe a few others

  • EXECUTE IMMEDIATE in error &gt; &gt; ORA-00972: identifier is too long

    Hello

    I wrote a code using execute immediate command. This command essentially creates a cursor that selects user_tab_columns table names. These table names are then used inside the statement immediately execute in order to apply the same select statement on the table being selected within the cursor names. The problem is that the above error is thrown saying identifier is too long. I can't understand how to solve this problem.

    Please find the below code:

    Declare
    Cursor C_1 is select distinct table_name
    of user_tab_columns
    where column_name = 'PROGRAM_UPDATE_DATE' AND table_name LIKE '% MISPA '.
    intersect
    Select unique table_name
    of gsi_daily_count;
    table_names varchar2 (100);
    Begin
    C_1 open;
    Loop
    Extract the C_1 in table_names;
    WHEN THE EXIT C_1% NOTFOUND;

    EXECUTE IMMEDIATE "select last_extract_date,
    TO_CHAR (min (largest (nvl (last_update_date, "1 January 10"), nvl (program_update_date, "1 January 10"))), "MON-DD-YY HH24:MI:SS") mi.
    TO_CHAR (max (greatest (nvl (last_update_date, "1 January 10"), nvl (program_update_date, "1 January 10"))), "MON-DD-YY HH24:MI:SS") my
    of ' | table_names |
    "Last_extract_date group".
    order of last_extract_date desc;';

    End loop;
    Close C_1;
    COMMIT;
    End;
    /


    Help, please.

    Kind regards
    Hossam
    declare
      cursor C_1
      is
      select distinct table_name
        from user_tab_columns
       where column_name = 'PROGRAM_UPDATE_DATE'
         and table_name LIKE 'MISPA%'
      intersect
      select unique table_name
        from gsi_daily_count;
    
      table_names varchar2(100);
    begin
      open C_1;
      loop
        fetch C_1 into table_names;
        exit when c_1%notfound;
    
        execute immediate
          'select last_extract_date,
                  to_char(min(greatest(nvl(last_update_date,''01-Jan-10''),nvl(program_update_date,''01-Jan-10''))),''DD-MON-YY HH24:MI:SS'') mi,
                  to_char(max(greatest(nvl(last_update_date,''01-Jan-10''),nvl(program_update_date,''01-Jan-10''))),''DD-MON-YY HH24:MI:SS'') ma
             from'|| table_names ||
          'group by last_extract_date
            order by last_extract_date desc;';
      end Loop;
      close C_1;
      commit;
    End;
    

    Here is the list of question I see in this code.

    1. in the SQL string, you must have a after the keyword and before the GROUP BY keyword.

    2. you should not use ';' in EXECUTE IMMEDIATE. You must remove it.

    3. the result set returned by the EXECUTE IMMEDIATE should be stored in a Variable. You use the INTO LEDGES INTO clause or in BULK to this effect.

  • Multibyte character sets

    Hi all

    Sql engine is 4 000 bytes for varchar2 columns supported by Oracle. No matter, we store 4000 (single byte) characters or characters multibyte n (where n < 4000). I'm skeptical for cases where the database supports multibyte characters. Can we have 4000 stored in a column varchar2 oracle multibyte characters? In any case (characterset)?

    Thank you

    OracleManiac wrote:

    Hi all

    Sql engine is 4 000 bytes for varchar2 columns supported by Oracle. No matter store us 4000 (single byte) characters or characters multibyte n (where n)<4000) .i="" am="" skeptical="" for="" those="" cases="" where="" the="" database="" supports="" multibyte="" characters="" .="" can="" we="" have="" 4000="" multibyte="" characters="" stored="" in="" a="" varchar2="" column="" in="" oracle="" in="" any="" case="">

    Thank you

    No - bytes equals bytes, and the limit for Oracle 11 and earlier versions is 4000 BYTES - no characters.

    If your characters each require 4 bytes you can store only 1,000 of them in a VARCHAR2 (4000).

    Refer to the section of the doc language SQL VARCHAR2 data type

    http://docs.Oracle.com/CD/B28359_01/server.111/b28286/sql_elements001.htm

    Regardless of the maximum length in characters, the length of VARCHAR2 data must not exceed 4000 bytes.

  • 10gr 2-11 GR 2 update: ORA-01722: invalid number

    10gr 2-11 GR 2 upgrade leads to ORA-01722: invalid number. Is it possible to fix this? Help, please.

    Thank you, Tyler!

    Please please refer to the below doc MOS

    Upgrade to 11g fails with ORA-01722: number invalid (Doc ID 730057.1)

    This is the solution to your problem

    You can also view the doc below

    "ORA-01722: invalid number" during upgrade/Downgrade (Doc ID 435536.1)

  • Selecting a SQL Server 2005 with names of long columns (&gt; 30 characters)

    Hello

    I was able to put in place a db Oracle 11.2.0.1 link to SQL Server 2005 using DG4ODBC.

    My problem is that some column names in Sql Server are more than 30 tanks and trying to select gives me the ORA-00972: identifier is a mistake too long.

    If I omit those select columns succeeds.
    I know that I can create a view in sql server and query it instead of the original table, but I was wondering if there is a way to overcome it with sql.

    My selection looks like this:
    select "good_column_name" from sometable@sqlserver_dblink -- this works
    select "good_column_name","very_long_column_name>30 chars" from sometable@sqlserver_dblink -- ORA-00972
    Thank you

    No there is no other way then using a view in SQl Server and select in the view rather than the table. The reason is that the Oracle database has a restriction that the column names must be 30 or fewer characters.

  • Create name synonymous with more than 30 characters.

    I created a synonym for a table which is over 30 characters long.
    After you have created the synonym with create synonym... created synonym message shows.
    but when I check in view object that syninym is not available, and
    Select * from < synonym_name > returtning nor the ranks.

    What is the reason for this? If oracle poster created as Syninym message then where his stored?

    Thanks in advance...

    To demonstrate the above...

    SQL> select * from user_synonyms;
    
    no rows selected
    
    SQL> create synonym MY_EMPLOYEE_RECORDS_VERY_LONG_NAME for EMP;
    
    Synonym created.
    
    SQL> select * from user_synonyms;
    
    SYNONYM_NAME                   TABLE_OWNER                    TABLE_NAME                     DB_LINK
    ------------------------------ ------------------------------ ------------------------------ ---------
    /9c4d39ff_MY_EMPLOYEE_RECORDS_ SCOTT                          EMP
    
    SQL> select * from MY_EMPLOYEE_RECORDS_VERY_LONG_NAME;
    select * from MY_EMPLOYEE_RECORDS_VERY_LONG_NAME
                  *
    ERROR at line 1:
    ORA-00972: identifier is too long
    
    SQL> select * from "/9c4d39ff_MY_EMPLOYEE_RECORDS_"
      2  ;
    
         EMPNO ENAME      JOB              MGR HIREDATE                   SAL       COMM     DEPTNO
    ---------- ---------- --------- ---------- ------------------- ---------- ---------- ----------
          7369 SMITH      CLERK           7902 17/12/1980 00:00:00        800                    20
          7499 ALLEN      SALESMAN        7698 20/02/1981 00:00:00       1600        300         30
          7521 WARD       SALESMAN        7698 22/02/1981 00:00:00       1250        500         30
          7566 JONES      MANAGER         7839 02/04/1981 00:00:00       2975                    20
          7654 MARTIN     SALESMAN        7698 28/09/1981 00:00:00       1250       1400         30
          7698 BLAKE      MANAGER         7839 01/05/1981 00:00:00       2850                    30
          7782 CLARK      MANAGER         7839 09/06/1981 00:00:00       2450                    10
          7788 SCOTT      ANALYST         7566 19/04/1987 00:00:00       3000                    20
          7839 KING       PRESIDENT            17/11/1981 00:00:00       5000                    10
          7844 TURNER     SALESMAN        7698 08/09/1981 00:00:00       1500          0         30
          7876 ADAMS      CLERK           7788 23/05/1987 00:00:00       1100                    20
          7900 JAMES      CLERK           7698 03/12/1981 00:00:00        950                    30
          7902 FORD       ANALYST         7566 03/12/1981 00:00:00       3000                    20
          7934 MILLER     CLERK           7782 23/01/1982 00:00:00       1300                    10
    
    14 rows selected.
    
    SQL>
    
  • Error ORA-39165 chain of schema not found.

    Hello
    When importing by impdp since an export dumpfile I error ORA-39165 scheme string is not found.
    1. How can I check that in the export dump file, there is no schema of the view? In imp utility we display option. Is there something for impdp?

    Thank you.

    See Note: 260225.1 Import DataPump parameter REMAP_SCHEMA - how to move objects from one schema to another database

    $ impdp system/****@mybase DUMPFILE=mydump.dmp remap_schema=schema1:schema2
    

    Of Note: 464558.1, it should also work:

    $ impdp schema2/****@mybase DUMPFILE=mydump.dmp remap_schema=schema1:schema2
    

    HTH

    Enrique

    PS, let us know how it went

    Published by: Enrique Orbegozo on October 22, 2008 08:00

  • Error in creation of the tablespace (ORA-000972)

    It's convenient, where I create a table with two data files space. You must use the exact naming conventions given to us. I think I have it right, but I get this error: "ORA-00972: identifier is too long. I think I'm getting it because the path and the name are so long. The question is, how to do this?

    Thank you!

    CREATE TABLESPACE CTTT444_tbs
    DATA file 'C:\oracle\product\10.2.0\oradata\cttt444_1.dbf' SIZE 15 M,
    DATA file 'C:\oracle\product\10.2.0\oradata\cttt444_2.dbf' SIZE 15 M,
    AUTOEXTEND ON
    NEXT 5 m
    MAXSIZE 100 m);

    you have 2 errors,

    First: change the * ' * by * "*".

    Second: create datafile in 2 different States

    * CREATE TABLESPACE CTTT444_tbs *.
    * "MY PATH\cttt444_1.dbf" DATAFILE SIZE 15 M *.
    * AUTOEXTEND ON *.
    * NEXT 5 m *.
    * MAXSIZE 100 m *.

    and THEN

    * ALTER TABLESPACE ADD DATAFILE... CTTT444_tbs *.

Maybe you are looking for