Cmn_1022 database driver error

We’re getting difficulties through an circumstances of Informatica / out-of-the-box OBIA on a new collection of servers. When we run the execution plan we gain this error soon after starting:

MAPPING> DBG_21075 Connecting to database , user MAPPING> CMN_1761 Timestamp Event: MAPPING> CMN_1022 Database driver error…CMN_1022

Database driver error…Function Name : ConnectDatabase Error: Faibrought about attach to database utilizing user and also link string .>

MAPPING> CMN_1761 Timestamp Event: MAPPING> CMN_1076 ERROR creating database connection.

You watching: Cmn_1022 database driver error

One or two tasks using the DataWareresidence link succeed, and then the remainder fail via the over error.

That one or two work succeed proves that the link string is stated correctly, plus I’d suppose to check out an auth error if our username/pw was incorrect. We’ve verified the Physical File Source in DAC, yet stupidly in Informatica (Workcirculation Manager – Connections – Relational) there’s no “test connection”.

Both of the errors, Informatica’s CMN_1022 and Oracle’s ORA-12537, are generic “somat’s bust” ones, neither giving a clue to what the difficulty is.

Metalink 3 has actually several entries for CMN_1022 yet they simply point to configuration/installation errors via the database connectivity.

There’s a matching short article on OTN Forums yet without a definitive solution

In DAC Physical File Sources the Max Num Connections is 10. The OTN forum posting describes performace so guessing perhaps Oracle wasn’t happy through the # of concurrent relationships I changed it to 1, but the difficulty remained.

This is on Informatica 8.1.1, Oracle client 10.2.0 and Oracle DB

See more: Kicked By Punkbuster; Restriction: Service Communication Failure: Pnkbstra.Exe

Our DBA had a look and also validated all the connectivity, and also granted the user DBA simply to make sure it wasn’t a priviledges problem.

I turned on tracing in the sqlclient (add trace_level_client=16 to the sqlnet.ora in $TNS_ADMIN) and also gained this rather useful output:

***********************************************************************Fatal NI connect error 12537, connecting to:(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(

VERSION INFORMATION:TNS for HPUX: Version – ProductionTCP/IP NT Protocol Adapter for HPUX: Version – ProductionTime: 25-MAR-2009 11:09:46Tracing to file: /app/oracle/product/informatica/server/bin/cli_2844.trcTns error struct:ns main err code: 12537TNS-12537: TNS:link closedns second err code: 12560nt major err code: 507TNS-00507: Connection closednt additional err code: 0nt OS err code: 0

and also delving right into the guts of the .trc file found:

(11) <25-MAR-2009 11:09:46:011> nsprecv: reading from transport…(11) <25-MAR-2009 11:09:46:011> nttrd: entry(11) <25-MAR-2009 11:09:46:100> nttrd: exit(11) <25-MAR-2009 11:09:46:100> ntt2err: entry(11) <25-MAR-2009 11:09:46:100> ntt2err: Read unmeant EOF ERROR on 38(11) <25-MAR-2009 11:09:46:100> ntt2err: exit(11) <25-MAR-2009 11:09:46:100> nsprecv: error exit(11) <25-MAR-2009 11:09:46:100> nserror: entry(11) <25-MAR-2009 11:09:46:101> nserror: nsres: id=0, op=68, ns=12537, ns2=12560; nt<0>=507, nt<1>=0, nt<2>=0; ora<0>=0, ora<1>=0, ora<2>=0

So probably it’s the DB server that’s not playing ball? I’m guessing the “Read unmeant EOF ERROR on 38” might be relevant.

///////////////////////////////////////////////////////////////Error found. Error Stack complies with for thread #: 11 id:0 Operation code:68 NS Error 1:12537 NS Error 2:12560NT Generic Error:507 Protocol Error:0 OS Error:0 NS & NT Errors Translation12537, 00000 "TNS:connection closed" // *Cause: "End of file" condition has actually been reached; companion has actually disassociated. // *Action: None needed; this is an indevelopment message./12560, 00000 "TNS:protocol adapter error" // *Cause: A generic protocol adapter error emerged. // *Action: Check addresses provided for correct protocol specification. Before // reporting this error, look at the error stack and also check for lower level // move errors.For even more details, rotate on tracing and also reexecute the // procedure. Turn off tracing as soon as the procedure is finish./00507, 00000 "Connection closed" // *Cause: Common "end of file" problem has actually been reached; partner has // disassociated. // *Action: None needed; this is an information message.////////////////////////////////////////////////////////////////which is the exact same error as I found in the trace file but with each code described.

We tested various permutations of servers:

Inf server A / 10g client -> DB Server A (11g) -> Fails Inf server A / 10g client -> DB Server Y (11g) -> SuccessInf server B / 10g client -> DB Server B (11g) -> SuccessInf server A / 10g client -> DB Server Z (10g) -> SuccessInf server C / 11g client -> DB Server C (11g) -> SuccessInf Server C / 11g client -> DB Server A (11g) -> Success

So now we have actually 3 similar setups (very same informatica/oracle client/oracle DB), two of which work, one stops working – as soon as run against Server A.

Our DBA ran a map on the listener on Server A and picked up this error:

TNS-12518: TNS:listener could not hand off client connectionTNS-12547: TNS:lost contactTNS-12560: TNS:protocol adapter errorTNS-00517: Lost contactHPUX Error: 32: Broken pipe

which points to a possible OS problem.

See more: Windows An Internal Error Occurred While Enumerating Backup Sets

The UNIX team checked the kernel settings in between DB Server A and also DB Server Y, however discovered no differences (in specific they checked maxuprc and also nproc).

This difficulty ultimately obtained refixed after two actions:

1) Database server was restarted2) Oracle PROCESSES was increased from 200 to 500

We suspect the rebegin addressed the difficulty as among the UNIX males spotted some “performance funnies” (technical term