ORA-02354: Error exporting/importing data, ORA-01555: snapshot too old: rollback segment number with the name "" too small

Similar Questions

• "Is:java.sql.SQLException error: ORA-01555: snapshot too old: rollback segment number with the name ' ' too small '.

  Hello

  We conduct apply CM which is a failure with the Error: "declared:java.sql.SQLException: ORA-01555: snapshot too old: rollback segment number with the name '' too small'."

  Its in our unique the production instance. I checked on the return parameter. Here are the details.

  SQL > show Cancel parameter

  VALUE OF TYPE NAME

  ------------------------------------ ----------- ------------------------------

  _in_memory_undo Boolean TRUE

  _undo_debug_usage integer 2

  UNDO_MANAGEMENT string AUTO

  UNDO_RETENTION integer 40000

  undo_tablespace string APPS_UNDOTS1

  SQL > select max (maxquerylen) of v$ undostat;

  MAX (MAXQUERYLEN)

  ----------------

  637116

  Please suggest what needs to be done to go further.

  
  

  Kind regards

  Prabhat.
  

  Post edited by: 942633

  Hello

  ORA-02067: the rollback transaction or registration required

  As mentioned, you will need to look at the design of the code:

  Error: ORA 2067
  Text: rollback transaction or registration required
  -------------------------------------------------------------------------------
  Cause: A failure (typically a trigger or a stored procedure with several updates remotely) has occurred, such as the execution of all or nothing from a previous call to Oracle cannot be guaranteed.
  Action: return to a previous point of backup or restore the transaction and resubmit.

  ------

  ORA-01555 caused by the following SQL statement (SQL ID: 5y0q4u8r2hdy9, query term s = 637608, SCN: 0x0bcc.4ed82762):

  ------

  ACTUAL SIZE [MB] UNDO UNDO RETENTION [s] NECESSARY UNDO SIZE [MB]

  ------------------------                   ------------------------------------------------------------------------- ------------------------

  304849 40000 267232.292

  To better help you, please let us know:

  -What is the function of this program.

  -Did you recently parameter changes until you have this error.

  Please ensure that the validation controls are implemented correctly, the DBA team and development will work hand in hand.

  Thank you &

  Best regards

• ORA-01555: snapshot too old: rollback segment number with the name ' ' too smal

  Hello team,
  
  We get below error in the concurrent program, after operating for 8 hours in Instance of Test. The same program works in PROD.
  Recently, we migrated version 12.1.2 EBS EBS version 12.1.3 2. This can be root causes?
  
  Any idea on this matter is much appreciated as Tracefiles/TKProfs are unable to give us clues
  
  
  ERROR on line 1:
  ORA-01555: snapshot too old: rollback segment number with the name "" too small
  ORA-06512: at the 'APPS '. Package_name", line 170
  ORA-06512: at line 1
  
  Thank you/SReddy

  http://docs.Oracle.com/CD/B19306_01/AppDev.102/b14258/d_stats.htm#i1036461

  Also check
  http://www.orafaq.com/wiki/ora-01555

• ORA-01555, snapshot too old: number of rollback segment 2 with the name '_SYSSMU1 '.

  Hello
  Oracle 10g,
  Im getting this error during the execution of a query
  
  Autoextend is enabled for the undo data file
  
  There are 6 GB of free space in the undo tablespace
  
  Before him was for undo_retention 18000.
  
  I have reset it using alter system command set to 25000.
  
  But it still gives the same error
  Please think about what could be the problem

  SQL> select (62057/60)/60 query,(25000/60)/60 retention
    2    from dual
    3  /
  
       QUERY  RETENTION
  ---------- ----------
  17.2380556 6.94444444
  

  Your question exectuing mandate is 17 hours while your cancel retention is about 7 hours, change your retention period of 20% extra with your queries execution order and then check your question again.

  at least the value cancel retention 75000, also you had better address your question why its too take so long?

  Khurram

• expdp error ORA-01555: snapshot too old

  Hi all -
  
  I've read a number of entries on this forum, but so far I've been unable to solve my problem. Running on Windows 2003 Server, Oracle 11 g 11.1.0.6.0
  
  I'm doing an expdp of my entire database. The only process that runs is the expdp. I closed all the user applications that make connections to the base. There is nothing written to this table and nothing read of him except expdp.
  
  . . exported "HDB_MAIN." "' WAVEFORM0 ' 64,64 GB 1811611 lines
  ORA-31693: Data Table object 'USERNAME '. "' WAVEFORM2 ' failed to load/unload and being ignored because of the error:
  ORA-02354: Error exporting/importing data
  ORA-01555: snapshot too old: rollback segment number 1 with the name ' _SYSSMU1_1193973708$ ' too small
  
  SQL > show Cancel parameter;
  
  VALUE OF TYPE NAME
  ------------------------------------ ----------- ------------------------------
  UNDO_MANAGEMENT string AUTO
  UNDO_RETENTION around 9000
  undo_tablespace string UNDOTBS1
  
  SQL > select sum (bytes) from WHERE user_segments where nom_segment = 'WAVEFORM2 ';
  
  SUM (BYTES)
  ----------
  7.7513E + 10 # this is about 72 GB, the largest table in the database
  
  I increased from 900 to 9000 undo_retention, but that made no difference. Undo_management being AUTOMATIC, I don't have control actually allocate more space for the segments of cancellation, right?
  
  (I have been a DBA before, but less experience with Oracle...)
  
  A few elements of "For what it worth":
  the final output file was 328 GB without WAVEFORM2. Still 193 GB of free disk target once the output file 328 GB was recorded there.
  oradata takes GB 946
  42.6 GB of free disk space on the drive oradata
  
  Any ideas on what I could look next?

  This error happens when you do not have sufficient value for undo_retention and undo tablespace size parameter.

• full database export error ORA-31693 ORA-01555: snapshot too old: rollback segment

  Hello

  normal full database export, I do it for my databases to which I subscribe. I recently check the export log in one of the databases, and it had the following errors:

  ORA-31693

  ORA-02354

  ORA-01555: snapshot too old: rollback segment

  my database is 11 GR 2 and the Linux environment.

  any help please?

  Hello

  This error indicates you have given LOB in your tables and binds to the parameter size undo_retention.

  Check this: https://geodatamaster.wordpress.com/2014/11/08/expdp-ora-31693-ora-02354-ora-01555/

  You must increase the size of undo_retention

• the nature of "ORA-01555: snapshot too old...» "error

  Hi all

  Please help me understand the nature of this error:

  ORA-01555: snapshot too old: rollback segment number 23 with the name ' _SYSSMU23_755263746$ ' too small

  One of the reports returns this error. Yes, I Googled, but honestly I don't deeply understand what makes. I have it usually disappear by running the sql query on copy of the production database yesterday. Is it correct to say that this error occurs when I try to make the request on the tables which are changed at the same time? What is the right solution to solve other than using the copy of the production database yesterday?

  The session receiving the error is often not the problem.  In general, there is another process that loads the data and enters a loop, but there are other reasons that it can cause.

  Two excellent coverage of the topic:

  http://asktom.Oracle.com/pls/Apex/f?p=100:11:0:P11_QUESTION_ID:275215756923

  http://www.oraclealchemist.com/Oracle/do-frequent-commits-fix-ora-01555/

• ORA-01555: snapshot too old: number of rollback segments

  Therefore on Oracle 11.2.0.2 on Solaris.  High level, we have a pretty large table on one of our Oracle dev instances, lines 430mil, where the data was populated by a large data load.  Two of our date fields have been left NULL so that we have to go back and update every row after the fact with SYSDATE values (some downstream applications require having some sort of date in this area).

  in any case, I wrote a script for this (truncated a bit for brevity):

  DECLARE
  ...
      ln_limit      NUMBER  := 10000; -- Max amount of records to process in a single bulk update statement    
      lv_total_rows INTEGER := 0;
      lv_count      NUMBER;
      lv_rowid      VARCHAR(18);
    
      CURSOR tco_cursor IS
          SELECT ROWID
          FROM LXRO
          WHERE LxModDate IS NULL;
    
      TYPE t_rows IS TABLE OF ROWID;
      lv_rowids t_rows;
    
  BEGIN
  ...
      OPEN tco_cursor;
      LOOP
    
          FETCH tco_cursor BULK COLLECT INTO lv_rowids LIMIT ln_limit;
        
          FORALL i IN 1 .. lv_rowids.COUNT
              UPDATE LXRO
              SET LxModDate = SYSDATE
              WHERE ROWID = lv_rowids(i);
  
  ...     -- (writes to log table here)          
          COMMIT;
  
          EXIT WHEN lv_rowids.COUNT < ln_limit;    
      END LOOP;
  
      CLOSE tco_cursor;
      COMMIT;
    
      EXCEPTION
      WHEN OTHERS THEN
          dbms_output.put_line(TO_CHAR(lv_rowid) || ' - ' || sqlerrm || ' - ' || TO_CHAR (ln_counter));
  END;
  /
  
  

  Only, the work runs for an hour and updates 37mil lines in a same test, and then gets the following error:

  ORA-01555: snapshot too old: rollback segment number 30 with name ' _SYSSMU30_4136132754$ ' too small

  I did some research on the error and read something interesting:

  Do not look around is committed. In other words, don't fetch on a slider was opened before the last commit, especially if the data surveyed by the slider is changed in the current session.

  Also, if the query is a loop with a commit in it, it can do the same without other queries, because finally the next iteration requires looking at his own first generation, cannot do so and barfs.

  Upping undo_retention may help, or not, as the real cause. See also v$ undostat, you may still have information in there, if it is current (or not, since at the time where you check the necessary info can be gone).

  I think that our UNDO tablspace has 16 GB now.  I do not try to hold back the 400 million lines in temp would be feasible, that's why I am committed all 10 k rows, more we ran into problems of memory with a version non-bulk this script before.  It will only be a time process (we have set our data migration to fill in these fields in future iterations).  Am I better choose to simply keep this job and re - keep on running for hours all the hours given the amount of data?  Is - this naïve to think that I could make this many updates without error in a single task running?

  Simply change the column and set the DEFAULT as SYSDATE clause. Now, you would not have to perform the update at all.

  And for the current issue, a single update could have questioned the size of the CANCELLATION. I guess that's what you're talking like memory problem. Good thing for you to do is to work with your DBA and Set configure your CANCELLATION as a result. If not enough UNDO available then you can split the update in the form of fixed numbers and run them, something like that.

  I used a 10-million limit. But you can work with your DBA and attempt to set even more.

  loop

  Update lxro set lxmoddate = sysdate where lxmoddate has the value null and rownum<=>

  commit;

  When the output sql % rowcount<>

  end;

  /

  Collect bulk copy the data in the PGA (private memory). It is a very expensive operation. Collect bulk was introduced mainly to reduce the change of context. But its performance is mediocre compared to direct SQL. So try to make your work in SQL right front.

• "ORA-01555: snapshot too old" during the cursor loop

  Hello
  
  I have a procedure which loop the records in a table, extracted SQL stored in one of the fields and execute it. In addition, it updates the State of education.
  Here is the code in the procedure.
  
  PROCEDURE RunStatements (inType IN NUMBER) IS
  -Declaration of the cursor:
  CURSOR cur_stmt (vType NUMBER) IS
  SELECT stmt_id, status, sql_stmt
  OF Stmts
  WHERE stmt_type = vType
  ORDER BY stmt_order;
  BEGIN
  
  -loop and run the statements:
  FOR r IN cur_stmt (inType) LOOP
  -updates the State
  UPDATE stmt
  SET status = 'On '.
  WHERE stmt_id = r.stmt_id;
  COMMIT;
  -running the SQL
  EXECUTE IMMEDIATE r.sql_stmt;
  COMMIT;
  -updates the State
  UPDATE stmt
  SET status = 'Off '.
  WHERE stmt_id = r.stmt_id;
  COMMIT;
  END LOOP;
  
  END;
  
  To parallelize the execution of the instructions, they are divided into two types: type 1 and type 2. The procedure is called via DBMS_JOB twice:
  
  Job 1:
  call RunStatements (1)
  Job 2:
  call RunStatements (2)
  
  The two executions of the procedure are running simultaneously for about 3 hours at night. Everything was OK until last week when an error began to occur every day.
  
  Here's the problem:
  
  One of the instructions is executed very long - around 1.5 hours. Successfully around 20 M, it inserts records into a table. However, after his arrival, Oracle triggers the following error:
  ORA-01555: snapshot too old: rollback segment number 7 with the name ' _SYSSMU7$ ' too small
  This error is issued after that Oracle is trying to retrieve the record next to the slider.
  After that I will carry out the rest of the statements manually and there is no problem.
  
  Oracle lost somehow, information about data in the cursor!
  
  Can someone help me understand why this is happening? Is it possible that the long running operation consumes the space reserved for the cursor? Is it possible that after a certain period of time without fetch all the records Oracle decides you don't need the cursor? Is it possible that the error is caused by using two identical slider?
  
  I tried to increase the tablespace UNDO as stated in some articles, but the error continues to appear.
  
  Any help will be appreciated. We are in production and I have to wake up every morning at 04:00 to start manually non-executed statements.
  
  Database: Oracle 10 g 2
  OS: Enterprise Linux RH
  
  Thank you in advance.
  
  Best regards
  Beroetz

  The reading consistency mechanism, this is what triggers the ORA-1555. We will try to explain what is happening:

  -T0, you open the slider. This locks "full" all the time the extraction will be requested (all read lines will be "full" t0). Note that Oracle does not have a copy of data of the cursor. When you check out lines, Oracle will read them disk/memory for now, ask you, not before (it will logically build the image in t0 if data has been changed since).

  -At t1, you update the validation and the stmt. When you retrieve a line of the cursor after t1, Oracle will see stmt has changed since t0 and logically will build the data as it was at t0, using the rollback segment information.

  ...
  time passes
  ...

  -To the t2 (2 hours after t0), you get a new line of the cursor. Oracle attempts to logically reconstruct the data as it was at t0, but information was crushed in the rollback segment. Oracle may come back in time indefinitely. The setting for the withholding of information of cancellation you defined is too low.

  You can either increase the retention time (undo_retention), it will have the effect to say Oracle: "wait longer before overwriting the cancellation information so that I can query the data to an earlier point in time. Or you can 'save cursor data' yourself, read all the lines, while you can (as before).

  I hope that this will help you understand why you get this error.

• ORA-01555: snapshot too old when there are expired blocks

  BANNER

  ----------------------------------------------------------------

  Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - production

  PL/SQL Release 10.2.0.4.0 - Production

  CORE 10.2.0.4.0 Production

  AMT for Linux: release 10.2.0.4.0 - Production

  NLSRTL Version 10.2.0.4.0 - Production

  We set the size cancellation tablspace to 2 GB with undo_retention duration of 1 hour.

  We get ORA-01555: snapshot too old: rollback segment number 51 with the name ' _SYSSMU51$ ' too small error when running the purge process.

  I want to know if there are expired blocks available and fly count for blocks remaining is 0, so why we get error ORA-01555.

  According to below the result of the query:

  
  

  EXPIREDBLKS = 138616

  UNXPSTEALCNT = 0

  set line 2000
  SELECT *
  FROM dba_hist_UNDOSTAT
  where ssolderrcnt <> 0
  
  
  
  
  

  BEGIN_TIME            END_TIME              DBID INSTANCE_NUMBER SNAP_ID UNDOTSN UNDOBLKS TXNCOUNT MAXQUERYLEN MAXQUERYSQLID MAXCONCURRENCY UNXPSTEALCNT UNXPBLKRELCNT UNXPBLKREUCNT EXPSTEALCNT EXPBLKRELCNT EXPBLKREUCNT SSOLDERRCNT NOSPACEERRCNT ACTIVEBLKS UNEXPIREDBLKS EXPIREDBLKS TUNED_UNDORETENTION
  --------------------- --------------------- ---- --------------- ------- ------- -------- -------- ----------- ------------- -------------- ------------ ------------- ------------- ----------- ------------ ------------ ----------- ------------- ---------- ------------- ----------- -------------------
  6/21/2014 10:15:21 AM 6/21/2014 10:25:21 AM 8337               2   50429       8    17969    27294       15780 77kuu26yggxym             19            0             0             0           0            0            0           1             0       9904       1549952      138616               13262
  
  
  
  

  > so why we get error ORA-01555.

  The session that signals the ORA-01555 is the victim; not the culprit.

  This session is probably made a LONG run SELECT against other tables.

  Done some session also DML against this same table and launches 'frequent' COMMIT (usually inside the LOOP).

  Eliminate common VALIDATION & the ORA-01555 error no longer is.

• OGG-00665 and ORA-01555: snapshot too old: s segment number of restore 3 with

  One of my clips added with the following error:
  
  OGG-00665 OIC error getting length of LOB for table (admin. column of T110) 393 (C2110001671) (status = 1555-ORA-01555: snapshot too old: s rollback)
  "" "" "" "" "" "" "" "" "" "" "" (egment numéro trop petit 3 avec le nom «_SYSSMU3_1278437183$»), SQL < SELECT x. "C1," x. "C2", x. "C3", x. "C4", x. "C5," x. "C6", x. "C7", x. "C8", x. "C112", x. "C536870915", x. "C536870916", x. "C53
  x 6870917,'. "" "" "" "" "" "C536870919", x. "C536870922", x. "C536870954", x. "C536870995", x. "C536870999", x. "C5368 >.
  
  
  UNDO_RETENTION already defined as 86400 a smaller number.
  
  What should I do here?
  
  All other parts work fine.
  
  Thank you

  When you increase your undo_retention, what happens?

  Error: ORA 01555
  "Text" snapshot too old: rollback segment %s with name \"%s\ number ' too small '.
  ----------------------------------------------------------------------------------------------
  Cause: records of restoration needed by a reader for consistent read are replaced by other writers
  Action: In Automatic Undo Management mode, increase the setting undo_retention. Otherwise, use a larger rollback segments

• ORA-01555 snapshot too old

  Hello
  
  In one of our production database we see error ORA-0155 quite frequently. Alert log reflects that this is caused by a number of select and insert. These statements are not always identical. Sometimes, we also receive this ORA-30036: unable to extend segment by 4 in undo tablespace "UNDOTBS1.
  
  The database version is 10.2.0.4 64bits. Undo retention is set with 1800 s, although the view v$ undostat it has been observed that the TUNED_UNDORETENTION reached quite high as the value specified in the settings file.
  
  Any suggestions on this will be highly appreciated.
  
  DB version: 10.2.0.4 64bits
  Platform: HP - UX itanium
  
  Thanks in advance for your valuable time.
  
  Kind regards
  Joy
  
  Published by: user8686720 on January 17, 2011 11:58

  It is is not only to defeat the size but also

  Publish.

  (1) what is the maximum length of queries in your database?

  Select MAXQUERYID, MAXQUERYLEN from v$ undostat;

  (2) what is the shelf life undo?

  See the paraemter cancel

  (1) need tuning SQL query.
  (2) increase the undo retention...
  (3) opt to CANCEL fixed.

  I suggest you read the article by tom as mentioned by SB. which is the best document of analysis

  * ORA-01555 "Snapshot too old" - detailed explanation [40689.1 ID] *.

  http://asktom.Oracle.com/pls/asktom/f?p=100:11:0:P11_QUESTION_ID:1441804355350

  SELECT d.undo_size /(1024*1024) 'REAL UNDO SIZE [MB]',
  SUBSTR (e.Value, 1, 25) "UNDO RETENTION [s]",
  ROUND ((d.undo_size / (to_number (f.value) *)))
  g.undo_block_per_sec))) "UNDO OPTIMAL RETENTION [s]"
  DE)
  SELECT SUM (a.bytes) undo_size
  V $ datafile has,.
  v$ tablespace b,.
  c dba_tablespaces
  WHERE c.contents = 'UNDO '.
  AND c.status = 'ONLINE '.
  AND b.name = c.tablespace_name
  AND a.ts # b.ts = #.
  ) d.
  v$ parameter e,.
  v$ parameter f,.
  (
  SELECT MAX (undoblks/((end_time-begin_time) * 3600 * 24))
  undo_block_per_sec
  V $ undostat
  ) g
  WHERE e.name = "undo_retention.
  AND f.name = 'db_block_size.

  Thank you.

• ORA-01555: snapshot too old: rollback segment number 7 with the name ' _SYSSMU7_1291102260$ ' too small

  
  Hello

  I get ORA-01555 error when performing the following procedure.

  CREATE OR REPLACE PROCEDURE proc1 (text in varchar2, varchar2 data type)
  AS

  L_STMT varchar2 (6000);
  number of l_exists;
  v_code NUMBER;
  v_errm VARCHAR2 (400);
  tabnam VARCHAR2 (100);
  colnam VARCHAR2 (100);
  
  cursor tab_cur is
  Select utc.table_name, utc.column_name, utc.data_type
  from user_tables utb, user_tab_columns utc
  where utc.table_name = utb. Table-name
  and NOT EXISTS (SELECT ' X'
  OF tl table_list
  WHERE the tl.table_name = utc.table_name)
  AND utc.data_type = 'VARCHAR2'
  ORDER OF THE UTC. TABLE_NAME;

  TYPE table_info_tt IS TABLE OF tab_cur % ROWTYPE;
  l_tab table_info_tt;

  BEGIN

  insert into m_log values (SYSTIMESTAMP, 'Start time');
  commit;

  OPEN tab_cur.
  LOOP
  
  Get the tab_cur COLLECT in BULK WITHIN the limits of the 1000 l_tab;
  
  FOR indx in 1.l_tab.count
  LOOP
  
  BEGIN
  
  L_STMT: = ' SELECT COUNT (1)
  OF ' | l_tab (indx). TABLE_NAME | ' WHERE ' | l_tab (indx). Column_name |' =: intext';
  run immediately L_STMT in l_exists using text;
  
  tabnam: = l_tab (indx). TABLE_NAME;
  colnam: = l_tab (indx). COLUMN_NAME;
  
  EXCEPTION
  
  WHILE OTHERS THEN
  
  L_STMT: = ' SELECT COUNT (1)
  OF ' | l_tab (indx). TABLE_NAME | » OÙ ' ||' » ' || l_tab (indx). COLUMN_NAME |' "' |' =: intext';
  run immediately L_STMT in l_exists using intext;
  
  tabnam: = l_tab (indx). TABLE_NAME;
  colnam: = l_tab (indx). COLUMN_NAME;
  END;
  
  IF (l_exists = 0) then
  
  null;
  
  on the other
  
  insert into ADM_TEXT_INFO
  values (l_tab (indx). Table_name, l_tab (indx). Column_name, text, data type);
  
  commit;
  
  END IF;
  
  END LOOP;
  
  EXIT WHEN l_tab.count = 0;
  
  END LOOP;
  
  CLOSE Tab_cur;
  
  insert into m_log values ("SYSTIMESTAMP," over time ");
  commit;
  exception
  while others then
  v_code: = SQLCODE;
  v_errm: = SUBSTR (SQLERRM, 1, 200);
  INSERT INTO VALUES error_log (v_code, v_errm, SYSTIMESTAMP);
  commit;
  DBMS_OUTPUT. Put_line (' error code:' | v_code |) ': ' || v_errm);
  
  END;
  /

  Details of database version are the following:

  Oracle Database 11 g Enterprise Edition Release 11.1.0.7.0 - 64 bit Production

  PL/SQL Release 11.1.0.7.0 - Production

  CORE Production 11.1.0.7.0

  AMT for Linux: Version 11.1.0.7.0 - Production

  NLSRTL Version 11.1.0.7.0 - Production

  
  SQL > show Cancel parameter

  VALUE OF TYPE NAME
  ------------------------------------ ----------- --------
  UNDO_MANAGEMENT string AUTO
  UNDO_RETENTION around 2000
  undo_tablespace string UNDOTBS1

  I changed the undo_retention and checked, it still gives the same error. The undo tablespace size is 23.7 GB (GB 23 is free, only 27 MB are used).

  Can anyone please suggest me, what could be the problem.

  Thank you

  SB2011

  Have a look here:

  Ask Tom & quot; SQL to retrieve a columns & quot;

• ORA-22924: snapshot too old

  Hello
  
  I use Oracle XE on Fedora. Everything by exporting a schema I get following error.
  
  EXP-00056: ORACLE error 1555
  ORA-01555: snapshot too old: rollback segment number with the name "" too small
  ORA-22924: snapshot too old
  
  
  Can someone help me please how to fix this.
  
  Thank you
  
  Habib

  ORA-22924: snapshot too old

  This message indicates, this is not a 'normal' cliché too old problem of the UNDO tablespace, you have corruption in a table being exported from MOS/metalink LOB segment:

  Export fails with ORA-02354 ORA-01555 ORA-22924 and how to confirm the Corruption of the LOB Segment using the export utility? [833635.1 ID]

• Getting ORA-22835: buffer too small for to CHAR CLOB or BLOB to RAW conversion in my ODI interface

  Hi all

  I am creating an interface ODI as explained below,

  I table A column 'Comments' and one other table with column B "No Comment." I create a view as shown below and use it as a source for my interface.

  SELECT * FROM WC_EQM_CSAP_FS_TMP WHERE to_char (QUESTION_COMMENT) IN (SELECT NO_COMMENTS FROM WC_EQM_NO_COMMENTS_LIST).

  But my interface fails with the error below

  ORA-22835: buffer too small for to CHAR CLOB or BLOB to RAW conversion (real: 4108, maximum: 4000)

  22835 00000 - "too small buffer tank CLOB or BLOB to RAW conversion (actual: %s, maximum: %s)) '

  * Cause: an attempt was made to convert CLOB to CHAR or BLOB to RAW, where

  LOB size was larger than the buffer for CHAR and RAW limit types.

  Note that the widths are reported in characters if characters length isadds are in effect for the column, other widths are

  in bytes.

  Here QUESTION_COMMENT is of type CLOB data. NO_COMMENTS is also CLOB data type. The maximum length of the data of QUESTION_COMMENT is also 11710

  Please tell us how to solve.

  Thank you

  Dany

  IMHO, it is not good to compare CLOB, can be that it is possible to use the primary key for the comments

  Is it QUESTION_COMMENT and NO_COMMENTS a PRIMARY INDEX,

  may be is the best solution to create vacabulary with comments (if it does not exist) and then compare it by id;

  You can simply use the left join and check for null in a CASE statement

  Try this, but I don't know... as I said before I have no Oracle DB

  SELECT INTEGRATION_ID, DATASOURCE_NUM_ID, QUESTIONNAIRE_ID, QUESTION_ID,

  CLIENT_ID, SITE_ID, CLIENT_REP, COMMITMENT, ENGAGEMENT_TYPE, TOP_CLIENT_FLG,

  INITIAL_PLANNED_DT, REVISED_PLANNED_DT, INTERVIEW_DT, RECEIVED_DT, QUESTION_SCORE,

  (

  CASE WHEN EXISTS (SOME T2.NO_COMMENTS OF WC_EQM_NO_COMMENTS_LIST T2 WHERE DBMS_LOB.COMPARE (TMP.) (QUESTION_COMMENT, T2.NO_COMMENTS) = 0)

  THEN NULL

  OF OTHER QUESTION_COMMENT

  END QUESTION_COMMENT),

  (CASE WHEN QUESTION_SCORE<=5 then="" 1="" else="" 0="" end)="">

  0 AS QWOCOMMENTS,

  CREATED_ON_DT, CHANGED_ON_DT OF WC_EQM_CSAP_FS_TMP as TMP

  P.S. does not use TO_CHAR (LOB) there are possible error