filling on server trace files

11.1.0.7 - 64-bit on Solaris

It seems tracing has been enabled on our database in the last week that trace the directory is to fill to the top.

However, it is what it is to show:

SQL > wear track of parameter

VALUE OF TYPE NAME

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

log_archive_trace integer 0

sec_protocol_error_trace_action string PATH

SQL_Trace boolean FALSE

trace_enabled Boolean TRUE

tracefile_identifier chain

It seems 11g have trace_enabled set to true by default.

My question is how can I find out who a session is drawn?

Thank you

Thank you all for your contributions.

It is now resolved by disabling tracking tab Top consumer of the control (GC) 11g of the grid as it was where he seems to be activated in the first place.

It has been activated for upper module which was the main application module and it was written several trace files every minute.

It would have been very difficult to resolve outside GC where it has been activated and it's a simple click is enough to accomplish on GC.

Thank you all

Tags: Database

Similar Questions

  • The server trace file sharing

    Hi all

    Our production database is 10.2.0.3 with 2 RAC nodes in the window MS 2003 servers. I wonder what kind of information that Oracle captures in the trace of the shared server file (file name looks like instance_s001_3333.trc). When I open some of these files I still see a single query always there along with messages like:

    WAITING #8: nam = 'gc cr block 2 ways' ela = 1222 p1 = p2 65 = 49677 p3 = 1 obj #= tim 69689 = 4137263779
    WAITING #8: nam = 'gc cr block 2 ways' ela = 593 p1 = p2 65 = 50863 p3 = 1 obj #= tim 69689 = 4137265531
    WAITING #8: nam = 'gc cr block 2 ways' ela = 592 65 p1 = p2 = 50879 p3 = 1 obj #= tim 69689 = 4137266700

    If we need to grant this request to make it disappear in the shared server trace files? What are the conditions to trigger Oracle put this request in the trace file?

    Thank you very much in advance for your support!

    Shirley

    I did a quick test with 10.2.0.1 EE on Linux with default shared server configuration. I have run your trace statements, and I see:
    -1 small file trace with the identifier of the EMT in USER_DUMP_DEST
    -1 large track .trc file s000 in BACKGROUND_DUMP_DEST.

    And it looks like the outcome according to trcsess doc. http://download.Oracle.com/docs/CD/B19306_01/server.102/b14211/SQLTrace.htm#PFGRF01050

    >
    However, in a shared server configuration a user session is served by different processes from time to time. The trace on the user session is dispersed across the different stack belonging to different processes.
    >

    Most traced statements are in the trace file to the shared server because it's the shared server that runs most of the SQL statements.

  • ADR TRACE FILES ARE FILL SPACE CUSTOMER BOXES

    I'm relatively new to 11g and the use of ADR. I realize of diagnosis of ADR, traces, newspapers, etc. are written in
    directories as specified in the diagnostic_dest parameter. In our case,.
    Under apps/oracle/diag/rdbms/rac1/rac13 where rac1 is our DNAME and
    rac13 is one of the names of the instance. I am also aware that tracking files are
    written under this path under the /trace and/incident/incdir_xxxxx
    directories.

    No HW or SW patches have been made recently.

    We know the problem of the our client application SW related boxes having
    their directory/root filled. As a result, all applications on these
    boxes of 'freeze '. Maybe it's something new for me, but I thought that the type of ADR
    diagnosis was only written to / exist ON DB SERVERS. We are witnessing to the
    the same type of files on CUSTOMERS - but in different directories. On the
    customer, for example, I see the following directories and the associated trace files
    by:
    1.) / root/oradiag_root/diag/clients/user_root/host_1204843186_11/incident/incdir_ *.
    and

    2.)/root/oradiag_root/diag/clients/user_root/host_1204843186_11/trace/ora__*.TRC & .trm

    ALL of these files and directories are user ny ROOT property. 4-5 of these files are created EVERY MINUTE in the track and incident
    directories, filling to the top/root. As a result, boxes of teas client application
    are suspended until the trace files are deleted.

    Here are my questions:
    1. What are these files?
    2.) why they are on the clients?
    (3.) if they are part of the ADR process g 11, can (and how) if we limit the frequency of their creation?
    I just need to put in place the crons to clean periodically?

    Thank you for any comments.

    Matt

    Hi Matt

    Wouw! I'm glad that you managed to solve this problem with the aid provided.

    Would you please so kind a also to mark my answer as correct or useful?
    Because this will help others to find a quick answer to questions and also ;) increase my rank

    On your other question:

    user10387007 wrote:

    After that I installed the adrci (assuming that there is a checkbox in the dbca client install for it), I'll start managing the adr and incident log file. Another question: do you suggest not to have to be running on the clients and servers in an environment operational adr? Logic for sure to development and test, but to question overhead compared to an OPS environment. Thank you!

    It makes sense on the server when it is a dev, test or pre-production environment. But on the production, I recommend you turn it on when you have a problem with the server or the client.

    Ask more questions if you have something to say!

    Thanks you also.

    Kind regards
    Hub

    Published by: Hub on November 22, 2008 10:46

  • Trace file has many references obj # but this oppose is nowhere in SQL statements

    Hi all

    Oracle 11.2.0.3 x 64 on x 64 Linux.

    No CARS.

    I have a trace file (captured with lie = true, wait = true) where inside, I have a large number of obj # references for the object that is not in the above trace file nowhere.

    Example of part of the trace file:

    ...

    PARSING IN CURSOR #22 len = dep 52 = uid 0 = 46 oct = cover 3 = 46 tim = hv 43179827168145 = ad 1014772292 = "c00000023baba230" sqlid = "amqq2ncy7sck4."

    Select TNC in PF_TRX where (CTN =: b0 and ROWNUM = 1)

    END OF STMT

    ANALYSIS #22:c = 0, e = 17, p = 0, cr = 0, cu = 0, set = 0, r = 0, dep = 0, og = 1, plh is 2442708035, tim = 43179827168144

    LINKS FOR #22:

    Link #0

    oacdty = 01 mxl = 32 (25) = 00 mxlc bad = 00 = 00 = 00 pre scl

    oacflg = 00 fl2 = 1000000 frm = 01 csi = 32 off siz = 32 = 0

    kxsbbbfp = 9fffffffbf5faba0 = 32 avl bln = 10 flg = 05

    value = "0606015172".

    EXEC #22:c = 0, e = 94, p = 0, cr = 0, cu = 0, set = 0, r = 0, dep = 0, og = 1, plh is 2442708035, tim = 43179827168314

    WAITING #22: nam ='SQL * Net message to client' ela = 1 driver id = 1413697536 #bytes = 1 p3 = 0 obj #= 775422 = 44216143020385 tim

    FETCH #22:c = 0, e = 13, p = 0, cr = 2, cu = 0, set = 0, r = 1, dep = 0, og = 1, plh is 2442708035, tim = 43179827168378

    "STAT id #22 = 1 cnt = 1 pid = 0 obj = 0 op = pos = 1' STOPKEY COUNTY (cr = 2 pr = 0 pw = time 0 = 0 US)"

    STAT #22 = 2 cnt = 1 pid = 1 pos = 1 obj id = 8236 op ='INDEX RANGE SCAN PF_TRX_1IX (cr = 2 pr = 0 pw = time 0 = 0 US cost = 1 size = 11 card = 1)'

    WAITING #22: nam ='SQL * Net client message' ela = 135 driver id = 1413697536 #bytes = 1 p3 = 0 obj #= 775422 tim = 44216143020630

    ...

    obj #= 775422 is an index into a schema user wealth of paintings, consideration of related things.

    But the picture, who own index which is never mentioned in the trace file all (DDL, DML, or Select statement).

    TKPROF does not display as well without the presence of this table.

    How to interpret these topics, as registrations in the event of mine is the biggest event of waiting.

    THX,

    Damir

    «SQL * Net message to client "is in fact a wait on the BONE (layers TCPIP).»  Oracle is not clear when the package reaches the customer, he knows only that she has presented the package to the TCPIP services provided by the operating system on the database server.

    Hemant K Collette

  • Phase of extraction in a trace file

    Oracle version: 11.2.0.3.0 Enterprise Edition
    Operating system - IBM/AIX RISC System/6000

    I'm trying to generate a trace file from a piece of code executed by the java server. What I asked the java developer to do is to place this block immediately after a connection is established:
    BEGIN
  EXECUTE IMMEDIATE 'ALTER SESSION SET TRACEFILE_IDENTIFIER = ''M1''';
  dbms_monitor.session_trace_enable(waits => FALSE, binds => TRUE);
END;
    And at the end of the block of logic java code:
    BEGIN
  dbms_monitor.session_trace_disable;
END;
    I want to know is how many lines the java Server recovers after executing a particular select statement, because they complain about getting less account lines select statement waits.
    For example, if I run the same query sql in the sqlplus session, then we'll, I extract say 1000 rows.
    When the same query is executed on the side of java, the lines of recoveries are less in number, let's say 500.
    And because I doubt it, I wanted to trace to see what is actually executed and how.
    The extract of the trace file I see exactly the same query that I myself run in a sqplus session.
    There is no precise control over the udnerlying tables in the query.

    And my question is, how to interpret the phase EXTRACTION of the slider (for the select statement)?
    For example, if I see a FETCH for this cursor, this means that the java server retrieves a single row?
    If I see 100 extractions, this means that they recovered 100 lines of the cursor?

    Here's a short excerpt from the trace file (please don't crucify me for obvious denormalized tables design, and the request it is not invented by me):
    PARSING IN CURSOR #4573587152 len=667 dep=0 uid=737 oct=3 lid=737 tim=17685516462413 hv=954980718 ad='70000006d3e4940' sqlid='69pm96nwfrqbf'
select /* ordered */ o.id, nvl(o.par_id, -1) as par_id, o.NAME_GER, o.NAME_ENG, o.NAME_ESP, o.NAME_ITL,o.NAME_FRA, decode(lo.lflag, 'Y', 'L', 'N') as leaf_or_node, lo.distance + 1 as "LEVEL",  to_char(o.beg_date, 'DD.MM.YYYY HH24:MI:SS'),  o.mais_id, l.path, nvl(o.non_selectable, 'N')  from   st_prod o, lprod_new l, lprod lo where  o.end_date = to_date('31.12.3999', 'DD.MM.YYYY') and   (lo.id, lo.beg_date) in (select id, beg_date from st_prod where par_id is null and end_date = to_date('31.12.3999', 'DD.MM.YYYY')) and   lo.lid = o.id and lo.lid_beg_date = o.beg_date and   l.st_prod_id = o.id and l.st_prod_beg_date = o.beg_date order by lo.distance, o.name_ger
END OF STMT
PARSE #4573587152:c=31,e=152,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2027551050,tim=17685516462412
EXEC #4573587152:c=80,e=375,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2027551050,tim=17685516462936

*** 2013-03-11 11:28:09.122
FETCH #4573587152:c=519446,e=892645,p=0,cr=113446,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517355715
FETCH #4573587152:c=37,e=59,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517359109
FETCH #4573587152:c=39,e=63,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517361128
FETCH #4573587152:c=29,e=46,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517362849
FETCH #4573587152:c=31,e=48,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517364621
<162 more FETCH-es here>
<STAT phase>
CLOSE #4573587152:c=533,e=849,dep=0,type=1,tim=17685517671878
    It is possible based on the trace file (if I have to change something in the way of tracing) to determine the number of rows retrieved? 
    FETCH #4573587152:c=519446,e=892645,p=0,cr=113446,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517355715
FETCH #4573587152:c=37,e=59,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517359109
FETCH #4573587152:c=39,e=63,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517361128
FETCH #4573587152:c=29,e=46,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517362849
FETCH #4573587152:c=31,e=48,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517364621

    Each FETCH call returns r = number of lines.

    Run TKPROF trace file for a readable activity summary.

    How to interpret the phase EXTRACTION of the slider (for the select statement)?

    The java code uses a default fetchsize to 10 (lines per extraction).

  • I can control the Trace files in bdump

    Experts in good morning...

    Question of BDUMP

    In BDUMP, I have the following files...

    -rw - r - 1 oracle oinstall 112687 19 Feb 13:41 alert_testdb.log
    -rw - r - r - 1 oracle oinstall 33068 Feb 19 12:03 alert_TSH1.log
    -rw - r - 1 oracle oinstall 20301 14 Feb 09:13 testdb_arc0_15379.trc
    -rw - r - 1 oracle oinstall 632 5 Feb 04:56 testdb_arc0_17339.trc
    -rw - r - 1 oracle oinstall 2118 Feb 5 05:22 testdb_arc0_17409.trc
    ... ..
    .... ..

    Totally 294 trace files...


    I checked some .trc files;  Almost have the same information.

    ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
    Name of the system: Linux
    Name of the node: xxxxxxxxxxxxxx
    News Release: xxxxxxxxxxxxxxxxxxxxxxxxxx
    Version: xxxxxxxxxxxxxxxxxxxxxxxxx
    Machine: xxxxxx
    Instance name: testdb
    Redo thread mounted by this instance: 1
    Oracle process number: 0

    My question clear is:

    1. If the alert log contains details of the error, what is the purpose of trace in bdump files?
    2. why "n" no trace files created without useful information? (Almost with the same information]
    3. what type of information is usually stored in .trc files?

    What I know about tracefiles:

    Each background process writes the trace files if an internal error has occurred.
    If I'm wrong, please correct.

    Trace files and log alerts serve a different purpose. A simple way to think about it, is that the trace files are used when diagnosing problems. The alert log shows you what are the events are occurring in the database in general, flooding you don't not with unnecessary details. If the database crashed, the alerts log will tell you when the event happened, but the details of the process that crashed would be (I hope) in a trace file.

    Some trace files are huge, and you certainly don't want them in the log of alerts because it would make it too big to be manageable or read.

    For example, if a process crashes, the dumping process trace file to would be useful when you are working with Oracle Support to identify the problem. Or, if you want to see what a specific session, you can turn on tracing on it and and then format the trace with tkprof file to understand what made the session.

    The documentation is a good summary:

    Trace files

    A trace file is an administrative file containing diagnostic data used to investigate the problems. Trace can also, provide guidance for tuning applications or an instance, as explained in "Diagnostic and performance optimization.

    Types of Trace files

    Each server and the background process can periodically write to a trace file. File information on the environment in the process, status, activities and errors.

    The SQL trace facility also created trace files, which provide information of performance on individual SQL statements. To enable tracing for an identifier of the client, service, module, action, session, instance or database, you must run the procedures in the DBMS_MONITOR package or use Oracle Enterprise Manager.

    A dump is a special type of trace file. Considering that track tends to be out of diagnostic data, a dump is usually a unique data output of diagnosis in response to an event (for example, an incident). When an incident occurs, the database writes one or more landfills in the incident directory created for the incident. Incident of discharges also contain the case number in the file name.

  • background trace file

    What is the use of the background trace file?
    How to stop the generation of trace files background?
    Version of DB - 10 g
    OS-win7

    Yes...

    You can set any size depending on the space on your server.

  • Generation of Oracle Trace files for a session

    Hello

    I use oracle 10g (10.2.0.5) in RHEL5 server. I used the instruction exec dbms_system.set_sql_trace_in_session (147,3,TRUE); to draw a particular session. I am able to track successfully, but I created a new table in this session where I'm not able to find any statement of create table in the trace file generated, but I can find the insert statements that I made on the table newly created in the trace file.

    Is not recorded in the events of path of the DDL statements?

    Kind regards

    007

    Salvation;

    Please find below the doc who can help you

    DBMS_SYSTEM. SET_SQL_TRACE_IN_SESSION GENERATES NO TRACE FOR THE SESSION ACTIVE [ID 236178.1]
    How to enable the SQL Trace for all new Sessions [ID 178923.1]

    Follow-up to the Sessions to Oracle using the package DBMS_SUPPORT [ID 62160.1]

    Respect of
    HELIOS

  • How to find trace files

    Hello...

    How can I get associated with a particular event trace files...

    I know the location of the trace files (< ORACLE_BASE > \diag\rdbms\orcl\orcl\trace) and also I can put name suffix of the trace files...

    I want to know... How to identify them it IE problems, so how can I get the trace file for this error...

    Please suggest... Thanks in advance...

    You can use the views of GDR

    http://docs.Oracle.com/CD/B28359_01/server.111/b28310/diag006.htm#CHDIHIBA

    http://docs.Oracle.com/CD/B28359_01/server.111/b28310/diag001.htm#CHDIABAA

  • 11 GR 2 trace file

    Hi all

    In my production database, the trace file occupies more than 40 GB of space. I can delete this file (adrci), but why they occupy so much space, a single file factor_ora_1880.trc (about 4 GB).
    The newspaper of the alerts for this trace file:
    Not critical error ORA-00001 intercepted when writing in the trace file '... \trace\factor_ora_1880.trc '.
    Error message: OSD-00002: additional error information
    S/O-error: (OS 87) the parameter is incorrect.
    Writing to the trace file that precedes is disabled for now on...

    P.S. Oracle Database 11g 11.2.0.1.0 (Patch 10155838( )
    MS Windows 2003 ServerR2 x 64


    Thank you.

    You can set the limit for a file path with MAX_DUMP_FILE_SIZE

    Check this box:
    http://download.Oracle.com/docs/CD/E11882_01/server.112/e17110/initparams135.htm#CHDIABEI

  • Trace file generated not.

    Hey guys,.

    I am using oracle 10g and is trying to generate a trace file.

    Using sql_Plus I see that timed_statistics is set to true, max_dump_file_size is set to unlimited, and user_dump_dest is set to C:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\DUMP.

    I run the script in Oracle SQL Developer:


    ALTER session set sql_trace = true;
    /

    ... Block PL/SQL which I want to trace...

    /
    ALTER session set sql_trace = false;
    /


    After that this sql runs without error there is no file on my computer in the user_dump_dest. In fact the path under user_dump_dest does not exist yet. What I first create the path? I looking in the wrong place? I do something wrong when setting sql_trace?

    Thank you
    Ian

    The trace file is written to the database server.

  • Help to read the trace file

    Hi Mike,.
    about my previous post HS Agent vs. Gateway,.
    It is the result of the trace file when the deadlock occurred.

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


    Oracle Corporation - Monday January 11, 2010 11:03:58.901


    Heterogeneous Agent release
    11.1.0.6.0




    Oracle Corporation - Monday January 11, 2010 11:03:58.900

    Version 11.1.0.6.0

    Hgogprd entries
    HOSGIP to 'HS_FDS_TRACE_LEVEL' returned 'DEBUG '.
    Hgosdip entries
    default assignment of 50 HS_OPEN_CURSORS
    HOSGIP returned the value of 'RECOVER' for HS_FDS_RECOVERY_ACCOUNT
    HOSGIP returned value for HS_FDS_RECOVERY_PWD
    layout HS_FDS_TRANSACTION_LOG or "HS_TRANSACTION_LOG".
    layout by default HS_FDS_TRANSACTION_ISOLATION of "READ_COMMITTED".
    layout by default «AL32UTF8» HS_NLS_NCHAR
    parameter HS_FDS_TIMESTAMP_AS_DATE if there is no 'TRUE '.
    layout HS_RPC_FETCH_REBLOCKING failure to 'ON '.
    HS_FDS_FETCH_ROWS layout without '100 '.
    parameter HS_FDS_RESULTSET_SUPPORT default 'FALSE '.
    parameter HS_FDS_PROC_IS_FUNC default 'FALSE '.
    parameter HS_FDS_CHARACTER_SEMANTICS default 'FALSE '.
    parameter HS_FDS_MAP_NCHAR if there is no 'TRUE '.
    setting HS_NLS_DATE_FORMAT or 'YYYY-MM-DD HH24:MI:SS ".
    parameter HS_FDS_REPORT_REAL_AS_DOUBLE default 'FALSE '.
    HS_LONG_PIECE_TRANSFER_SIZE layout without "65536".
    parameter HS_SQL_HANDLE_STMT_REUSE default 'FALSE '.
    parameter HS_FDS_QUERY_DRIVER default 'FALSE '.
    HS_CALL_NAME_ISP layout "gtw$: SQLTables; GTW$: SQLColumns. GTW$: SQLPrimaryKeys. GTW$: SQLForeignKeys. GTW$: SQLProcedures. "gtw$: SQLStatistics.
    Release of hgosdip, rc = 0
    ORACLE_SID is 'sysdevdsn '.
    Product information:
    Port RLS / Upd:6 / 0 PrdStat:0
    Agent: Oracle Database Gateway for MSSQL
    : Installation
    Class: MSSQL, ClassVsn:11.1.0.6.0_0006, Instance: sysdevdsn
    Release of hgogprd, rc = 0
    Hgoinit entries
    HOCXU_COMP_CSET = 1
    HOCXU_DRV_CSET = 31
    HOCXU_DRV_NCHAR = 873
    HOCXU_DB_CSET = 31
    HOCXU_SEM_VER = 90200
    Entry hgolofn at 2010/01/11-11: 03:58
    ODBCINST value ' / oracle11g/ora11_1g/dg4msql/driver/dg4msql.loc '.
    RC =-1 of HOSGIP for 'LD_LIBRARY_PATH '.
    LD_LIBRARY_PATH to environment is "/ oracle11g/ora11_1g/dg4msql/pilot/lib: / lib/ora11_1g/oracle11g."
    Affecting LD_LIBRARY_PATH "/ oracle11g/ora11_1g/dg4msql/pilot/lib: / oracle11g/ora11_1g/dg4msql/pilot/lib: / lib/ora11_1g/oracle11g."
    HOSGIP to 'HS_FDS_SHAREABLE_NAME_ICU' returned ' / oracle11g/ora11_1g/dg4msql/driver/lib/libHGicu22.so '.
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf4c6008
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    HOSGIP to 'HS_FDS_SHAREABLE_NAME_INST' returned ' / oracle11g/ora11_1g/dg4msql/driver/lib/libodbcinst.so '.
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf4c7330
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    HOSGIP to 'HS_FDS_SHAREABLE_NAME' returned ' / oracle11g/ora11_1g/dg4msql/driver/lib/libodbc.so '.
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34eca0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ecb0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ecc0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ecd0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ece0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ecf0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ed00
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ed10
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ed20
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ed30
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ed40
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ed50
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ed60
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ed70
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ed80
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ed90
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34eda0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34edb0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34edc0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34edd0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ede0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34edf0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ee00
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ee10
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ee20
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ee30
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ee40
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ee50
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ee60
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ee70
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ee80
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ee90
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34eea0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34eeb0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34eec0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34eed0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34eee0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34eef0
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ef00
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ef10
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ef20
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ef30
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Entry hgolofns at 2010/01/11-11: 03:58
    symbol_peflctx = 0xbf34ef40
    hoaerr:0
    Output hgolofns 2010/01/11-11: 03:58
    Release of hgolofn, rc = 0 at 2010/01/11-11: 03:58
    HOSGIP to 'HS_OPEN_CURSORS' returned '50 '.
    HOSGIP to 'HS_FDS_FETCH_ROWS' returned '100 '.
    HOSGIP for "HS_LONG_PIECE_TRANSFER_SIZE" returned "65536".
    HOSGIP to 'HS_NLS_NUMERIC_CHARACTER' returned '. "
    Release of hgoinit, rc = 0 at 2010/01/11-11: 03:58
    Entry hgolgon at 2010/01/11-11: 03:58
    name: B2CUPLOAD, reco:0, tflag:0
    Entry hgosuec at 2010/01/11-11: 03:58
    UEncoding = UTF8
    Entry shgosuec at 2010/01/11-11: 03:58
    Release of shgosuec, rc = 0 at 2010/01/11-11: 03:58
    returned shgosuec() rc = 0
    Release of hgosuec, rc = 0 at 2010/01/11-11: 03:58
    HOSGIP to 'HS_FDS_RECOVERY_ACCOUNT' returned 'RECOVER '.
    HOSGIP to 'HS_FDS_TRANSACTION_LOG' returns ""HS_TRANSACTION_LOG"
    HOSGIP for "HS_FDS_TIMESTAMP_AS_DATE" returns 'TRUE '.
    HOSGIP to 'HS_FDS_CHARACTER_SEMANTICS' returned 'FALSE '.
    HOSGIP for "HS_FDS_MAP_NCHAR" returns 'TRUE '.
    HOSGIP to 'HS_FDS_RESULT_SET_SUPPORT' returned 'FALSE '.
    HOSGIP to 'HS_FDS_PROC_IS_FUNC' returned 'FALSE '.
    HOSGIP to 'HS_FDS_REPORT_REAL_AS_DOUBLE' returned 'FALSE '.
    using B2CUPLOAD as a default value to "HS_FDS_DEFAULT_OWNER".
    HOSGIP to 'HS_SQL_HANDLE_STMT_REUSE' returned 'FALSE '.
    Entry hgocont at 2010/01/11-11: 03:58
    HS_FDS_CONNECT_INFO = "cs - sql2:1049 / / sysdev.
    RC =-1 of HOSGIP for 'HS_FDS_CONNECT_STRING '.
    Entry hgogenconstr at 2010/01/11-11: 03:58
    DSN:CS - sql2:1049 / / sysdev, name: B2CUPLOAD
    OPTN:
    Entry shgogohn at 2010/01/11-11: 03:58
    Release of shgogohn, rc = 28500 at 2010/01/11-11: 03:58
    Entry hgocont_OracleCsidToIANA at 2010/01/11-11: 03:58
    Back 4
    Output hgocont_OracleCsidToIANA 2010/01/11-11: 03:58
    # > connection settings (len = 202) < #.
    # DRIVER = Oracle 11 g dg4msql;
    # Address = cs-sql2, 1049;
    # Database = sysdev;
    #! UID = B2CUPLOAD;
    #! PWD = *.
    # AnsiNPW = Yes;
    # QuotedId = Yes;
    # IANAAppCodePage = 4;
    # ArraySize = 100;
    # PadVarbinary = 0;
    # SupportNumericPrecisionGreaterThan38 = 1;
    Release of hgogenconstr, rc = 0 at 2010/01/11-11: 03:58
    DriverName:HGmsss22.so, DriverVer:05.20.0100 (b0062, u0033)
    DBMS name: Microsoft SQL Server DBMS Version: 08.00.2039
    Release of hgocont, rc = 0 at 2010/01/11-11: 03:58
    SQLGetInfo Returns Y for SQL_CATALOG_NAME
    SQLGetInfo Returns 128 for SQL_MAX_CATALOG_NAME_LEN
    Release of hgolgon, rc = 0 at 2010/01/11-11: 03:58
    Entry hgoulcp at 2010/01/11-11: 03:58
    Entry hgowlst at 2010/01/11-11: 03:58
    Release of hgowlst, rc = 1 at 2010/01/11-11: 03:58
    SQLGetInfo Returns Y for SQL_PROCEDURES
    Release of hgoulcp, rc = 0 at 2010/01/11-11: 03:59
    Entry hgouldt at 2010/01/11-11: 03:59
    Release of hgouldt, rc = 0 at 2010/01/11-11: 03:59
    Entry hgobegn at 2010/01/11-11: 03:59
    tflag:0, original: 1
    Hoi:0xffffe1b8, ttid (len 38) is...
    00: 4149 534543 4 434C 4D42532E 5552452E [MBS. CLAIMSECURE.]
    10: 31613362 38643035 2E372E39 [COM.1a3b8d05.7.9] 434F4D2E
    20: 2E333330 3038 [. 33008]
    tbid (len 10) is...
    0: F0800000 07000900 0104 [...]
    Release of hgobegn, rc = 0 at 2010/01/11-11: 03:59
    Entry hgodtab at 2010/01/11-11: 03:59
    number: 1
    Table: DBO. B2C_PIN_PROFILE
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:1 (BP_PIN_ID): dtype:12 (VARCHAR), prc / scl:15 / 0, nullbl:0, byte: 15, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:2 (BP_PIN_STATUS): dtype:1 (CHAR), prc / scl:1 / 0, nullbl:0, byte: 1, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:3 (BP_CREATE_DATE): dtype:93 (TIMESTAMP), prc / scl:23 / 3, nullbl:0, byte: 1, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:4 (BP_ACTIVE_DATE): dtype:93 (TIMESTAMP), prc / scl:23 / 3, nullbl:1, byte: 1, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:5 (BP_LAST_LOGON_DATE): dtype:93 (TIMESTAMP), prc / scl:23 / 3, nullbl:1, byte: 1, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:6 (BP_TERM_DATE): dtype:93 (TIMESTAMP), prc / scl:23 / 3, nullbl:1, byte: 1, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:7 (BP_PSWD): dtype:12 (VARCHAR), prc / scl:255 / 3, nullbl:1, byte: 255, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:8 (BP_PSWD_RESET): dtype:1 (CHAR), prc / scl:1 / 3, nullbl:1, byte: 1, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:9 (BP_PSWD_DATE): dtype:93 (TIMESTAMP), prc / scl:23 / 3, nullbl:1, byte: 1, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:10 (BP_EMAIL_ADDRESS): dtype:12 (VARCHAR), prc / scl:50 / 3, nullbl:0, byte: 50, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:11 (BP_IP_ADDRESS): dtype:12 (VARCHAR), prc / scl:100 / 3, nullbl:1, byte: 100, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:12 (BP_URL_REFERER): dtype:12 (VARCHAR), prc / scl:255 / 3, nullbl:1, byte: 255, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:13 (BP_IN_CERT): dtype:1 (CHAR), prc / scl:10 / 3, nullbl:1, byte: 10, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:14 (BP_IN_GRP): dtype:1 (CHAR), prc / scl:6 / 3, nullbl:1, byte: 6, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:15 (BP_IN_FIRST_NAME): dtype:12 (VARCHAR), prc / scl:30 / 3, nullbl:1, byte: 30, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:16 (BP_IN_LAST_NAME): dtype:12 (VARCHAR), prc / scl:40 / 3, nullbl:1, byte: 40, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:17 (BP_IN_DOB): dtype:93 (TIMESTAMP), prc / scl:23 / 3, nullbl:1, byte: 40, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:18 (BP_IN_QUESTION): dtype:12 (VARCHAR), prc / scl:255 / 3, nullbl:1, byte: 255, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:19 (BP_IN_ANSWER): dtype:12 (VARCHAR), prc / scl:255 / 3, nullbl:1, byte: 255, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:20 (BP_DB_CREATE_DATE): dtype:93 (TIMESTAMP), prc / scl:23 / 3, nullbl:1, byte: 255, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:21 (BP_DB_SOURCE): dtype:1 (CHAR), prc / scl:1 / 3, nullbl:1, byte: 1, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:22 (BP_DB_RELATIONSHIP): dtype:1 (CHAR), prc / scl:2 / 3, nullbl:1, byte: 2, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:23 (BP_DB_DIV): dtype:1 (CHAR), prc / scl:3 / 3, nullbl:1, byte: 3, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:24 (BP_DB_UNIT): dtype:1 (CHAR), prc / scl:3 / 3, nullbl:1, byte: 3, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:25 (BP_DB_FIRST_NAME): dtype:12 (VARCHAR), prc / scl:30 / 3, nullbl:1, byte: 30, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:26 (BP_DB_LAST_NAME): dtype:12 (VARCHAR), prc / scl:40 / 3, nullbl:1, byte: 40, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:27 (BP_DB_GRP_TYPE): dtype:1 (CHAR), prc / scl:1 / 3, nullbl:1, byte: 1, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:28 (BP_DB_CERT_EFF_DATE): dtype:93 (TIMESTAMP), prc / scl:23 / 3, nullbl:1, byte: 1, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:29 (BP_DB_INS): dtype:1 (CHAR), prc / scl:4 / 3, nullbl:1, byte: 4, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:30 (BP_HOLD_EFT): dtype:-7 (BIT), prc / scl:1 / 0, nullbl:1, byte: 4, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:31 (BP_PROVIDER): dtype:1 (CHAR), prc / scl:14 / 0, nullbl:1, byte: 14, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:32 (BP_BENEFIT): dtype:1 (CHAR), prc / scl:2 / 0, nullbl:1, byte: 2, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopcda at 2010/01/11-11: 03:59
    Column:33 (BP_CORP_EMAIL_ADDRESS): dtype:12 (VARCHAR), prc / scl:100 / 0, nullbl:1, byte: 100, sign: 1, radix: 0
    Release of hgopcda, rc = 0 at 2010/01/11-11: 03:59
    The hoada for the dbo. B2C_PIN_PROFILE follows...
    hgodtab, line 577: print hoada @ 600000000035bfa0
    MAX: 33, REAL: 33, BRC:1, WHT = 6
    DTY NULL-OK LEN MAXBUFLEN PR/SC CSE IND MOD NAME
    12 VARCHAR N 15 15 0 / 0 0 0 0 BP_PIN_ID
    1 TANK 1 1 N 0 0 0 0 0 BP_PIN_STATUS
    N DATE 91 16 16 0 / 0 0 0 0 BP_CREATE_DATE
    Y DATE 91 16 16 0 / 0 0 0 0 BP_ACTIVE_DATE
    Y DATE 91 16 16 0 / 0 0 0 0 BP_LAST_LOGON_DATE
    Y DATE 91 16 16 0 / 0 0 0 0 BP_TERM_DATE
    12. IS VARCHAR 255 255 0 / 0 0 0 0 BP_PSWD
    1 CHAR Y 1 1 0 0 0 0 0 BP_PSWD_RESET
    Y DATE 91 16 16 0 / 0 0 0 0 BP_PSWD_DATE
    12 VARCHAR N 50 50 0 / 0 0 0 0 BP_EMAIL_ADDRESS
    12 YEARS OF VARCHAR 100 100 0 / 0 0 0 0 BP_IP_ADDRESS
    12. IS VARCHAR 255 255 0 / 0 0 0 0 BP_URL_REFERER
    1 CHAR Y 10 10 0 / 0 0 0 0 BP_IN_CERT
    TANK 1 Y 6 6 0 / 0 0 0 0 BP_IN_GRP
    12 YEARS OF VARCHAR 30 30 0 / 0 0 0 0 BP_IN_FIRST_NAME
    12 YEARS OF VARCHAR 40 40 0 / 0 0 0 0 BP_IN_LAST_NAME
    Y DATE 91 16 16 0 / 0 0 0 0 BP_IN_DOB
    12. IS VARCHAR 255 255 0 / 0 0 0 0 BP_IN_QUESTION
    12. IS VARCHAR 255 255 0 / 0 0 0 0 BP_IN_ANSWER
    Y DATE 91 16 16 0 / 0 0 0 0 BP_DB_CREATE_DATE
    1 CHAR Y 1 1 0 0 0 0 0 BP_DB_SOURCE
    TANK 1 Y 2 2 0 0 0 0 0 BP_DB_RELATIONSHIP
    TANK 1 Y 3 3 0 / 0 0 0 0 BP_DB_DIV
    TANK 1 Y 3 3 0 / 0 0 0 0 BP_DB_UNIT
    12 YEARS OF VARCHAR 30 30 0 / 0 0 0 0 BP_DB_FIRST_NAME
    12 YEARS OF VARCHAR 40 40 0 / 0 0 0 0 BP_DB_LAST_NAME
    1 CHAR Y 1 1 0 0 0 0 0 BP_DB_GRP_TYPE
    Y DATE 91 16 16 0 / 0 0 0 0 BP_DB_CERT_EFF_DATE
    1 TANK 4 4 Y 0 / 0 0 0 0 BP_DB_INS
    -7-BIT 1 1 Y 0 / 0 0 0 20 BP_HOLD_EFT
    1 CHAR Y 14 14 0 / 0 0 0 0 BP_PROVIDER
    TANK 1 Y 2 2 0 0 0 0 0 BP_BENEFIT
    12 YEARS OF VARCHAR 100 100 0 / 0 0 0 0 BP_CORP_EMAIL_ADDRESS
    Release of hgodtab, rc = 0 at 2010/01/11-11: 03:59
    Entry hgodafr, cursor id 0 at 2010/01/11-11: 03:59
    Release of hgodafr, rc = 0 at 2010/01/11-11: 03:59
    Entry hgotcis at 2010/01/11-11: 03:59
    SQLStatistics requires the DBO. B2C_PIN_PROFILE
    IndexType SQL_TABLE_STAT =: cardinality = 114894
    New index: PK_BP_PIN_ID, = 1, ASCENDING, SINGLE type, cardinality = 114894
    ordinal position = 1
    New index: IDX_BP_IN_CERT, type = 3, ASCENDANT, NON-UNIQUE, cardinality = 114894
    ordinal position = 1
    New index: IDX_PROVIDER_B2C_PIN_PROFILE, type = 3, ASCENDANT, NON-UNIQUE, cardinality = 114894
    ordinal position = 1
    ordinal position = 2
    Call to SQLColumns to DBO. B2C_PIN_PROFILE
    Column 'BP_PIN_ID': dtype = 12, colsize = 15, decdig = 0, char_octet_length = 15, len line cumulative avg = 11
    Column 'BP_PIN_STATUS': dtype = 1 colsize = 1, decdig = 0, char_octet_length = 1, len cumulative average line = 12
    Column 'BP_CREATE_DATE': dtype = 93, colsize = 23, decdig = 3, = 1 char_octet_length, cumulative avg line len = 28
    Column 'BP_ACTIVE_DATE': dtype = 93, colsize = 23, decdig = 3, = 1 char_octet_length, cumulative avg line len = 44
    Column 'BP_LAST_LOGON_DATE': dtype = 93, colsize = 23, decdig = 3, = 1 char_octet_length, cumulative avg line len = 60
    Column 'BP_TERM_DATE': dtype = 93, colsize = 23, decdig = 3, = 1 char_octet_length, cumulative avg line len = 76
    Column 'BP_PSWD': dtype = 12, colsize = 255, decdig = 3, char_octet_length = 255, len line cumulative avg = 267
    Column 'BP_PSWD_RESET': dtype = 1 colsize = 1, decdig = 3, char_octet_length = 1, len cumulative average line = 268
    Column 'BP_PSWD_DATE': dtype = 93, colsize = 23, decdig = 3, = 1 char_octet_length, cumulative avg line len = 284
    Column 'BP_EMAIL_ADDRESS': dtype = 12, colsize = 50 decdig = 3, char_octet_length = 50, len line cumulative avg = 321
    Column 'BP_IP_ADDRESS': dtype = 12, colsize = 100, decdig = 3, char_octet_length = 100, len line cumulative avg = 396
    Column 'BP_URL_REFERER': dtype = 12, colsize = 255, decdig = 3, char_octet_length = 255, len line cumulative avg = 587
    Column 'BP_IN_CERT': dtype = 1, colsize = 10, decdig = 3, char_octet_length = 10, len line cumulative avg = 597
    Column 'BP_IN_GRP': dtype = 1, colsize = 6, decdig = 3, char_octet_length = 6, len line cumulative avg = 603
    Column 'BP_IN_FIRST_NAME': dtype = 12, colsize = 30, decdig = 3, char_octet_length = 30, len line cumulative avg = 625
    Column 'BP_IN_LAST_NAME': dtype = 12, colsize = 40, decdig = 3, char_octet_length = 40, len line cumulative avg = 655
    Column 'BP_IN_DOB': dtype = 93, colsize = 23, decdig = 3, char_octet_length = 40, len line cumulative avg = 671
    Column 'BP_IN_QUESTION': dtype = 12, colsize = 255, decdig = 3, char_octet_length = 255, len line cumulative avg = 862
    Column 'BP_IN_ANSWER': dtype = 12, colsize = 255, decdig = 3, char_octet_length = 255, len line cumulative avg = 1053
    Column 'BP_DB_CREATE_DATE': dtype = 93, colsize = 23, decdig = 3, char_octet_length = 255, len line cumulative avg = 1069
    Column 'BP_DB_SOURCE': dtype = 1 colsize = 1, decdig = 3, char_octet_length = 1, len cumulative average line = 1070
    Column 'BP_DB_RELATIONSHIP': dtype = 1, colsize = 2, decdig = 3, = 2 char_octet_length, len line cumulative avg = 1072
    Column 'BP_DB_DIV': dtype = 1, colsize = 3, decdig = 3, char_octet_length = 3, len line cumulative avg = 1075
    Column 'BP_DB_UNIT': dtype = 1, colsize = 3, decdig = 3, char_octet_length = 3, len line cumulative avg = 1078
    Column 'BP_DB_FIRST_NAME': dtype = 12, colsize = 30, decdig = 3, char_octet_length = 30, len line cumulative avg = 1100
    Column 'BP_DB_LAST_NAME': dtype = 12, colsize = 40, decdig = 3, char_octet_length = 40, len line cumulative avg = 1130
    Column 'BP_DB_GRP_TYPE': dtype = 1 colsize = 1, decdig = 3, char_octet_length = 1, len cumulative average line = 1131
    Column 'BP_DB_CERT_EFF_DATE': dtype = 93, colsize = 23, decdig = 3, = 1 char_octet_length, cumulative avg line len = 1147
    Column 'BP_DB_INS': dtype = 1, colsize = 4, decdig = 3, char_octet_length = 4, len line cumulative avg = 1151
    Column 'BP_HOLD_EFT': dtype = - 7, colsize = 1, decdig = 0, char_octet_length = 4, len line cumulative avg = 1155
    Column 'BP_PROVIDER': dtype = 1, colsize = 14, decdig = 0, char_octet_length = 14, len line cumulative avg = 1169
    Column 'BP_BENEFIT': dtype = 1, colsize = 2, decdig = 0, char_octet_length = 2, len line cumulative avg = 1171
    Column 'BP_CORP_EMAIL_ADDRESS': dtype = 12, colsize = 100, decdig = 0, char_octet_length = 100, len line cumulative avg = 1246
    Release of hgotcis, rc = 0 at 2010/01/11-11: 03:59
    Entry hgopars, id of cursor 1 at 2010/01/11-11: 03:59
    type: 0
    Text SQL hgopars, id = 1, len = 195...
    45 00: 53454 C 43542022 42505F50 494E5F49 [BP_PIN_I SELECT ' ']
    10: 22 44222C 42505F50 494E5F53 54415455 [D', BP_PIN_STATU ' "]
    20: 22 53222C 42505F41 43544956 455F4441 [S', BP_ACTIVE_DA ' "]
    30: 5445222 C 2242505F 494E5F43 45525422 [TE', 'BP_IN_CERT']
    40: 2 C 5F494E5F C 224250 47525022 2, 224250 ['BP_IN_GRP', 'BP]
    50: 52454 41 54494F4E 53484950 5F44425F [_DB_RELATIONSHIP]
    60: 22204652 4F4D2022 44424F22 2E224232 ["FROM"DBO".] ["B2]
    70: 435F5049 4E5F5052 4F46494C 45222057 [C_PIN_PROFILE' W]
    80:48455245 20224250 5F494E5F 47525022 [HERE "BP_IN_GRP"]
    90: 3D3F2041 4E442022 42505F49 4E5F4345 [=? AND 'BP_IN_CE] '.
    A0: 5254223D 3F20414E 44202242 505F4442 [RT '=? AND 'BP_DB] '.
    B0: 5F52454C 4154494F 50223 27 4E534849 [_RELATIONSHIP"=" "]
    C0: 4 4227 [MO ']
    Release of hgopars, rc = 0 at 2010/01/11-11: 03:59
    ----------------------

    I don't know how to read this. can anyone help?

    Thank you
    Lie

    Salvation lie,.
    Well, I'll control the thread for updates.

    Kind regards
    Mike

  • LMS huge trace file created

    Hi all

    2 CARS db in window Server 2003 nodes. The version of db is 10.2.0.3. My question is why we get huge lms trace files in the bdump directory and they become bigger and bigger. In the trace file, we have something like the following. Thanks a lot for your help, Shirley

    2009-12-29 10:11:01.926
    KJM_HISTORY: OP (12) of STALL RCVR context 0 elapsed 651716247 US
    KJM HIST LMS3:
    12:651716247 7:1 6:0 10:1 17:1 16:0 15:1 12:15475015 7:1 6:1
    10:0 17:2 16:1 15:291 12:651692189 7:1 6:1 10:0 17:1 16:1
    12:12345971 15:1 7:0 6:1 10:0 17:1 16:0 15:1 12:12020 7:0
    6:1 10:0 17:1 16:1 15:0 12:11977 7:1 6:0 10:0 17:1
    16:1 15:0 12:12054 7:1 6:0 10:0 17:1 16:1 15:0 12:12016
    7:1 6:0 10:0 17:1 16:1 12:12017 7:1 6:0 10:0 15:0
    17:1 16:1 15:0 12:11692
    ----------------------------------------
    SO: 000000012A3B11D8, type: 4, owner: 000000012A0041B8, flag: INIT /-/-/ 0x00
    (session) sid: 543 trans: 0000000000000000, creator: 000000012A0041B8, flag: (51) USR /-BSY /-/ - /-/ - / -.
    DID: 0000-0000-00000000, DID short term: 0000-0000-00000000
    TXN branch: 0000000000000000
    Oct: 0, prv: 0, sql: 0000000000000000, psql: 0000000000000000, users: 0/SYS
    last wait "gcs remote message" blocking sess = 0 x 0000000000000000 seq = 10 wait_time = 651716241 seconds since then started to wait = 300
    waittime = 18, survey = 0, event = 0
    Dumping history of waiting for Session
    for "BSC remote messages" number = 1 wait_time = 651716241
    waittime = 18, survey = 0, event = 0
    for "BSC remote messages" number = 1 wait_time = 15475008
    waittime = 18, survey = 0, event = 0
    for "BSC remote messages" number = 1 wait_time = 651692179
    waittime = 18, survey = 0, event = 0
    for "BSC remote messages" number = 1 wait_time = 12345963
    waittime = 18, survey = 0, event = 0
    for "BSC remote messages" number = 1 wait_time = 12017
    waittime = 18, survey = 0, event = 0
    for "BSC remote messages" number = 1 wait_time = 11974
    waittime = 18, survey = 0, event = 0
    for "BSC remote messages" number = 1 wait_time = 12052
    waittime = 18, survey = 0, event = 0
    for "BSC remote messages" number = 1 wait_time = 12013
    waittime = 18, survey = 0, event = 0
    for "BSC remote messages" number = 1 wait_time = 12014
    waittime = 18, survey = 0, event = 0
    for "BSC remote messages" number = 1 wait_time = 11688
    waittime = 18, survey = 0, event = 0
    the temporary object counter: 0
    ----------------------------------------
    UOL used: 0 locks (used = 0, free = 0)
    KGX atomic operation Log 000007FFE6FF5600
    Mutex 0000000000000000 (0, 0) oper idn 0 NONE
    Library Cache 543 DTS uid 0 w/h 0 slp 0
    KGX atomic operation Log 000007FFE6FF5648
    Mutex 0000000000000000 (0, 0) oper idn 0 NONE
    Library Cache 543 DTS uid 0 w/h 0 slp 0
    KGX atomic operation Log 000007FFE6FF5690
    Mutex 0000000000000000 (0, 0) oper idn 0 NONE
    Library Cache 543 DTS uid 0 w/h 0 slp 0

    check metalink note:
    excessive LMS and lmd of sizes of trace files generated on windows rac - 437101.1

    HTH
    -André

  • Large number of trace files generated

    Many of the following trace files are current generted throughout the day, sometimes 4/5 per minute

    There is nothing in the alerts log

    Any ideas?

    Thanks in advance

    ________________________________________________________________

    E:\oracle\admin\nauti1\udump\nauti1_ora_5552.TRC dump file
    Kills Nov 18 17:36:11 2008
    ORACLE V10.2.0.4.0 - Production vsnsta = 0
    vsnsql = 14 vsnxtr = 3
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
    Windows Server 2003 V5.2 Service Pack 2 Version
    CPU: type 4-586, 4 physical cores
    Process affinity: 0x00000000
    Memory (success/Total): Ph: 2045 M / 3839 M, Ph + FCP: 3718 M / 5724 M, GOES: 649 M / 2047 M
    Instance name: nauti1

    Redo thread mounted by this instance: 1

    Oracle process number: 32

    Windows thread ID: 5552, image: ORACLE. EXE (SHAD)


    ACTION NAME :() 2008-11-18 17:36:11.432
    MODULE NAME: (Nautilus.Exe) 2008-11-18 17:36:11.432
    SERVICE NAME: (nauti1) 2008-11-18 17:36:11.432
    SESSION ID: (130.42066) 2008-11-18 17:36:11.432
    KGX cleaning...
    KGX atomic operation Log 342CD2A4
    Mutex 452CC5F8 (130, 0) idn 0 oper EXAM
    Cursor Parent uid 130 DTS 17 w/h 26 slp 0
    Oper = DEFAULT pt1 = 00000000 00000000 00000000 = pt2 = pt3
    PT4 = 00000000 u41 TWU 0 = 0 =
    KGX cleaning...
    KGX atomic operation Log 342CD2A4
    Mutex 452CC5F8 (130, 0) idn 0 oper EXAM
    Cursor Parent uid 130 DTS 17 w/h 26 slp 0
    Oper = DEFAULT pt1 = 48265D6C 48265E68 = 48265D3C pt2 = pt3
    PT4 = 00000000 u41 TWU 0 = 0 =
    E:\oracle\admin\nauti1\udump\nauti1_ora_5552.TRC dump file
    Sat 22 Nov 12:52:32 2008
    ORACLE V10.2.0.4.0 - Production vsnsta = 0
    vsnsql = 14 vsnxtr = 3
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
    Windows Server 2003 V5.2 Service Pack 2 Version
    CPU: type 4-586, 4 physical cores
    Process affinity: 0x00000000
    Memory (success/Total): Ph: 2070 M / 3839 M, Ph + FCP: 3896 M / 5724 M, GOES: 673 M / 2047 M
    Instance name: nauti1

    Redo thread mounted by this instance: 1

    Oracle process number: 29

    Windows thread ID: 5552, image: ORACLE. EXE (SHAD)

    See metalink Bug 6638558 bug description

  • CoreTelephony error in trace file as a file for coretelephony tracing operation has failed, perhaps you need more disk space. Details "error opening the file/tmp/ct.shutdown, err = operation not permitted

    I got this error:

    "CoreTelephony Trace file error
    A file for CoreTelephony tracing operation failed, you might run out of disk space. Details "error opening the file/tmp/ct.shutdown, err = operation not permitted"

    I tried to solve it by searching for CoreTelephony errors. Could not resolve yet.
    Software does not, especially of photoshop...

    Any ideas?

    Same thing here, iMac with OS X 10.11.6. All started a couple days ago. Have not found any valid solution online yet, I tried rebooting in recovery mode and check disk, but it seems that everything is ok with the drives and permissions.

Maybe you are looking for