Results 1 to 10 of 10
  1. #1
    Join Date
    Jan 2004
    Posts
    19

    Exclamation Unanswered: Ora:03113 Ora:03114

    ORA:03113-end of communication channel
    ORA:03114-not connected to ORACLE

    I receive these messages when trying to run certain powerbuilder reports from my Oracle app. My version of Oracle is 8.0.6 which was just upgraded. I have 1gig of memory and swap space looks like is set to 2344mb. SQL*Net was recycled as well as listener.ora, but the message remains. The alert_dbname.log lists a core dump access violation, but I gather this means a disconnection warning or timeout message, right? All other functions of my application work and even short reports work fine. The only reports that trigger these errors are reports with lots of updates and views. Any suggestions on what could be the problem?

  2. #2
    Join Date
    Jan 2004
    Location
    India
    Posts
    113
    It seems that disconnection is forced on you.
    There could be a number of reasons for that.
    Network problem--Check network trafficking
    check sql net.ora file
    check listener process (lsnrctl stat)
    Instance problem-- U can drop the instance and recreate it using oradim utility.

    Oracle_sid variable is not set properly.

    Hope these helps
    Good luck
    Kaushik

  3. #3
    Join Date
    Jan 2004
    Location
    Scottsdale, AZ
    Posts
    106

    Exclamation

    I would not recommend following any instructions for dropping an instance unless you are pretty certain that you have a complete cold backup of everything you need to recreate that instance. Good intention instructions can yield devastating results.

    I would suggest determing why the powerebuilder reports that are doing lots of updates are causing a core dump. Don't assume that the core dump was created by the loss of communication. Perhaps the loss of communication was due to whatever generated the core dump.

    Perhaps something within the updates is generating the core dump. Too many times the assumption 'nothing is wrong with my code', results in something being wrong in the code.

    You mentioned that these are long running. Perhaps there is a timeout value set in sqlnet.ora?
    "Take Control!
    Make The Choice!
    Accept The Consequences!
    Deal With The Results! "

  4. #4
    Join Date
    Apr 2003
    Location
    Greenville, SC (USA)
    Posts
    1,155

    Exclamation

    I highly agree dbtoo2001 !!!! It is probably unlikely that the instance is causing a core dump ......

    As mentioned, check SQLNET.ORA to see if you have a timeout set as
    well as profiles setup that have an expire time set.

    be more specific with error message and error number:

    "alert_dbname.log lists a core dump access violation"


    Gregg

  5. #5
    Join Date
    Jan 2004
    Location
    India
    Posts
    113
    Ok my friends agreed Instance dropping or recreating is not recommended but do we actually need an offline or cold backup to recreate an instance I think hot backup(downtime reduced) backup is sufficeint enough to do that.

    Sorry for my friend who has posted this problem , for deviating from ur probs.

    It will better if u trace events and paste the error message alongwith the post.

    One more question do u have enough size in rollback segments to hold ur updates?
    Last edited by kausik_m123; 02-27-04 at 14:41.

  6. #6
    Join Date
    Jan 2004
    Posts
    19

    Exclamation

    Here are snippets of my sql*net.ora and alert log files...

    The #SQLNET.EXPIRE_TIME = 0 in my sql* net

    rollback_segments = RB0, RB1, RB2, RB3, RB4, RB5, RB6, RB7, RB8, RB9, RB10, RB11, RB12, RB13, RB14, RB15, RB16, RB17, SYS2ROL, SYSROL, CTXROL

    Sat Feb 21 13:02:53 2004
    alter database "advance" open
    Beginning crash recovery of 1 threads
    Sat Feb 21 13:02:54 2004
    Thread recovery: start rolling forward thread 1
    Recovery of Online Redo Log: Thread 1 Group 10 Seq 758936 Reading mem 0
    Mem# 0 errs 0: E:\ADVANCE\ADV_LOGS\LOG10PROD.ORA
    Mem# 1 errs 0: F:\ADVANCE\ADV_LOGS\LOG10PROD.ORA
    Sat Feb 21 13:02:54 2004
    Thread recovery: finish rolling forward thread 1
    Thread recovery: 1 data blocks read, 1 data blocks written, 1 redo blocks read
    Crash recovery completed successfully
    Picked broadcast on commit scheme to generate SCNs


    Mon Feb 23 15:16:27 2004
    Errors in file E:\orant\rdbms80\trace\ORA00217.TRC:

    Tue Feb 24 11:10:58 2004
    Errors in file E:\orant\rdbms80\trace\ORA00124.TRC:
    tfil

  7. #7
    Join Date
    Apr 2003
    Location
    Greenville, SC (USA)
    Posts
    1,155
    Ok ... Where's the beef ... Please post the errors that you have in
    the trace files ....

    Gregg

  8. #8
    Join Date
    Jan 2004
    Location
    Scottsdale, AZ
    Posts
    106
    (First 100 lines or so only, don't need to see the whole thing posted.)
    Only now can we deduce that this running on NT or Windoze 2K ( and 8.0.6 is downlevel:

    Desupport End Dates: Error Correction Support (ECS): 30-SEP-2001
    Extended Support (ES): 30-SEP-2004
    Extended Maintenance Support (EMS): 30-SEP-2003


    Product Obsolescence / Desupport Information:
    Oracle Corporation announces the end of Error Correction Support for Oracle Database version(s) 8.0.6 & 8.0.6.x on the following platform(s): ALL Platforms, effective 30-SEP-2001.
    Oracle Corporation recommends customers upgrade/migrate to the following as soon as possible to maintain the highest level of support: Oracle Database 8.1.7 on any Oracle certified platform.

    ES will be provided until 30-SEP-2004, if the customer has a current support contract in place.
    ).
    "Take Control!
    Make The Choice!
    Accept The Consequences!
    Deal With The Results! "

  9. #9
    Join Date
    Jan 2004
    Posts
    19
    FATAL ERROR IN TWO-TASK SERVER: error = 12571
    *** 2004-02-23 15:16:27.062
    ksedmp: internal or fatal error



    Looks like this is the problem, huh??
    tfil

  10. #10
    Join Date
    Jan 2004
    Location
    Scottsdale, AZ
    Posts
    106
    Closer - still probably a problem in the powerbuilder forms (have you backed up the database lately?) From Metalink:

    fact: Oracle Server - Enterprise Edition
    symptom: Errors appear in alert file
    symptom: FATAL ERROR IN TWO-TASK SERVER:
    symptom: ERROR = 12571
    symptom: trace file generated
    symptom: Database operations continue successfully
    cause: The most common cause for the above error is an ungraceful
    disconnection of a session from the oracle db while the db is currently running
    a dml statement issued by that session. The error is recorded when oracle
    attempts to reply back to the session with the results of the dml and cannot
    access the session. Overall database operations are usually not affected.

    An ungraceful disconnection could cause by but is not limited to any of the
    following:
    - the client machine crashed
    - the network connection crashed
    - the user exited the session improperly (not issuing the 'exit' command)
    - the user application allows the user to exit the application without properly
    terminating the session.

    The above can cause problems with corrupted rollback segments if occurring on a
    regular basis and is not addressed. This would require db recovery and
    possibly a db rebuild (not a light matter)

    PMON will usually rollback most transactions in the rollback segments for a
    session if it finds that the session has been ungracefully disconnected, but
    there is always a chance that it cannot and this will lead to rollback segment
    corruption.



    fix:

    The dml and the user that issued the dml can be determined from the trace file.
    The current dml is in the tracefile header section. The user can be found in
    the process state dump of the trace. The process state shows the machine,
    o/suser, and user for the session.

    The DBA can use this information to determine what the user was doing at the
    time and if there was an ungraceful exit from the session the user was
    utilizing.

    The DBA should then address the cause of the ungraceful exit to reduce the
    possibility of reoccurance.
    "Take Control!
    Make The Choice!
    Accept The Consequences!
    Deal With The Results! "

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •