Prev: -1555-ORA-01555: snapshot too old: rollback segment number 7 with name "_SYSSMU7$" too small
Next: Oracle Chaining
From: DA Morgan on 16 Oct 2006 16:08
Jochen Erfurt wrote:

>>> Server: Windows 2003 Server SP2
>>> ORACLE 10.2
>>>
>>> Clients: Windows 2000 Server SP4 (with Citrix)
>>> ORACLE 8.1.7 Client
>>>

>> Wait a second 8.1.7 client connecting to 10gR2? Surely you jest.
>> Reconsider this configuration choices.
>
> Sorry, but I do not understand.
>
> Thank you and best regards
>
> Jochen

I'd have thought the obvious incompatibility ... trying to use
a 10 year old client to connect to a current database would be
obvious. Upgrade the client software.

And if you don't understand what is in the log files ... post
the contents.
--
Daniel A. Morgan
University of Washington
damorgan(a)x.washington.edu
(replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
From: Charles Hooper on 16 Oct 2006 17:44
Jochen Erfurt wrote:
> Dear Daniel,
>
> "DA Morgan" <damorgan(a)psoug.org> schrieb im Newsbeitrag
> news:1161011702.730726(a)bubbleator.drizzle.com...
> > Jochen Erfurt wrote:
> >> Hello,
> >>
> >>
> >> <frank.van.bortel(a)gmail.com> schrieb im Newsbeitrag
> >> news:1161001732.683503.103040(a)m73g2000cwd.googlegroups.com...
> >>> Jochen Erfurt schreef:
> >>>
> >>>> Hello All,
> >>>>
> >>>> we have a problem connecting to an Oracle DB 10.2 in a Windows
> >>>> environment.
> >>>>
> >>>> In the servers listener.log I found the following errors:
> >>>>
> >>>> TNS-12518: TNS: Listener konnte Client-Verbindung nicht weitergeben
> >>>> TNS-12560: TNS: Fehler bei Protokolladapter
> >>>> TNS-00530: Protokolladapter-Fehler
> >>>> 32-bit Windows Error: 2: No such file or directory
> >>>>
> >>>> There are no problems connecting to the Db on the server, when the
> >>>> Windows
> >>>> OS user on the client pc (local or domain user) does have admin rights,
> >>>> the
> >>>> connection works fine as well.
> >>>>
> >>>> Solution one: Each user will have full admin right. I guess the IT will
> >>>> not
> >>>> like me any more...
> >>>>
> >>>> Any other ideas?
> >>>>
> >>> Fail to see where the admin rights come in...
> >>> What is the error on the client side? What OS version?
> >>>
> >>
> >> Server: Windows 2003 Server SP2
> >> ORACLE 10.2
> >>
> >> Clients: Windows 2000 Server SP4 (with Citrix)
> >> ORACLE 8.1.7 Client
> >>
> >> Windows 2003 Server SP2 (Terminal Server)
> >> ORACLE 10.2 Client
> >>
> >> Login on Windows client as normal or power user
> >> connection to database fails
> >>
> >> Login on Windows client as lokal or domain admin
> >> connection to database established
> >>
> >> As soon as an connection to the DB is established (e.g. via rdp and Admin
> >> login) the normal OS user cann connect as well to the DB?!?
> >>
> >> Thanks and best regards,
> >> Jochen
> >
> > Please try to provide the information required for someone to help you.
> >
> > The client connection to the database fails?
>
> Yes, the client connection to the database fails.
>
> >
> > With what error message?
>
> LISTENER.LOG
> TNS-12518: TNS:listener could not hand off client connection
> TNS-12560: TNS:protocol adapter error occurred
> TNS-00530: Protocol adapter error
> 32-bit Windows Error: 2: No such file or directory
>
> > What is the client software application?
>
> A Centura based third party ERP application. In Centura I receive the
> following message:
>
> connect tbbt kw/poeffel
> ^
> Error: 02554 SRV X54 Oracle specific error reported; more information
> available
>
> And in the Centura trace file the following error message:
>
> 10/16/06 17:29:34 1> [oracon] login string kw(a)TBBT
> 10/16/06 17:29:34 0> [ERROR] 2554 ORA-01019: unable to allocate memory in
> the user side
>
> I guess this is misleading, the server and instance works fine for weeks -
> before the Windows User rights have been changed.
>
> > Have you turned on SQLNET tracing?
>
> Yes, I just did, but I do not understand the content. Before I post the
> complete file: What exactly should I look for?
>
> >
> > Wait a second 8.1.7 client connecting to 10gR2? Surely you jest.
> > Reconsider this configuration choices.
>
> Sorry, but I do not understand.
>
> Thank you and best regards
>
> Jochen

We have a couple commercial programs that were written in Centura
SQLWindows which connect to our 10g R2 (10.2.0.2) database using the
Oracle 8.0.5, 8.1.7, and 10.2.0.1 Oracle clients. You can _probably_
eliminate the Oracle client version as the problem.

This may indicate a communication problem. Centura based applications
require an entry in the SQL.INI file on the client computer that points
to the correct entry in the TNSNAMES.ORA file. You should see
something like this in the SQL.INI file under the heading [oragtwy]
remotedbname=TBBT,@TNS:TBBT

Make certain that the non-domain admin user has read permissions on the
SQL.INI file and the Oracle install folder. Make certain that
ORACLE_HOME\oracore\zoneinfo\timezone.dat is accessible on the client
computer and on the server. Verify that there are not duplicate files
on the client computer, such as OCIW32.dll, which may be for a
different version of the Oracle client. Make certain that the NLS
settings are correctly set. The client may be trying to create a
temporary file in an unexpected location (maybe a client side trace) -
FileMon should be able to spot this problem.

Charles Hooper
PC Support Specialist
K&M Machine-Fabricating, Inc.

From: Jochen Erfurt on 17 Oct 2006 08:00
Hello Daniel,


"DA Morgan" <damorgan(a)psoug.org> schrieb im Newsbeitrag
news:1161029331.270788(a)bubbleator.drizzle.com...
> Jochen Erfurt wrote:
>
>>>> Server: Windows 2003 Server SP2
>>>> ORACLE 10.2
>>>>
>>>> Clients: Windows 2000 Server SP4 (with Citrix)
>>>> ORACLE 8.1.7 Client
>>>>
>
>>> Wait a second 8.1.7 client connecting to 10gR2? Surely you jest.
>>> Reconsider this configuration choices.
>>
>> Sorry, but I do not understand.
>>
>> Thank you and best regards
>>
>> Jochen
>
> I'd have thought the obvious incompatibility ... trying to use
> a 10 year old client to connect to a current database would be
> obvious. Upgrade the client software.

Meanwhile I have checked with an ORACLE 10 Client. The failure still exist.

> And if you don't understand what is in the log files ... post
> the contents.

I do know log files. In the log there is no error statement, thus I am
asking before posting.

What I did not understand is your question and your statement:
"Wait a second 8.1.7 client connecting to 10gR2? Surely you jest."

I haven't been precise, the effect I have with the second client is: Once I
have an open connection to the database (loged on with the windows admin in
the first session, e.g. the server console ) I can connect the database as
normal user (loged on in a second session, e.g. a client pc).


Bets regards,
Jochen





From: Jochen Erfurt on 17 Oct 2006 08:00
Hello Charles,

thanks for you comments. Pleas see my remarks below.

"Charles Hooper" <hooperc2000(a)yahoo.com> schrieb im Newsbeitrag
news:1161035067.010459.196180(a)k70g2000cwa.googlegroups.com...
> Jochen Erfurt wrote:
>> Dear Daniel,
>>
>> "DA Morgan" <damorgan(a)psoug.org> schrieb im Newsbeitrag
>> news:1161011702.730726(a)bubbleator.drizzle.com...
>> > Jochen Erfurt wrote:
>> >> Hello,
>> >>
>> >>
>> >> <frank.van.bortel(a)gmail.com> schrieb im Newsbeitrag
>> >> news:1161001732.683503.103040(a)m73g2000cwd.googlegroups.com...
>> >>> Jochen Erfurt schreef:
>> >>>
>> >>>> Hello All,
>> >>>>
>> >>>> we have a problem connecting to an Oracle DB 10.2 in a Windows
>> >>>> environment.
>> >>>>
>> >>>> In the servers listener.log I found the following errors:
>> >>>>
>> >>>> TNS-12518: TNS: Listener konnte Client-Verbindung nicht
>> >>>> weitergeben
>> >>>> TNS-12560: TNS: Fehler bei Protokolladapter
>> >>>> TNS-00530: Protokolladapter-Fehler
>> >>>> 32-bit Windows Error: 2: No such file or directory
>> >>>>
>> >>>> There are no problems connecting to the Db on the server, when the
>> >>>> Windows
>> >>>> OS user on the client pc (local or domain user) does have admin
>> >>>> rights,
>> >>>> the
>> >>>> connection works fine as well.
>> >>>>
>> >>>> Solution one: Each user will have full admin right. I guess the IT
>> >>>> will
>> >>>> not
>> >>>> like me any more...
>> >>>>
>> >>>> Any other ideas?
>> >>>>
>> >>> Fail to see where the admin rights come in...
>> >>> What is the error on the client side? What OS version?
>> >>>
>> >>
>> >> Server: Windows 2003 Server SP2
>> >> ORACLE 10.2
>> >>
>> >> Clients: Windows 2000 Server SP4 (with Citrix)
>> >> ORACLE 8.1.7 Client
>> >>
>> >> Windows 2003 Server SP2 (Terminal Server)
>> >> ORACLE 10.2 Client
>> >>
>> >> Login on Windows client as normal or power user
>> >> connection to database fails
>> >>
>> >> Login on Windows client as lokal or domain admin
>> >> connection to database established
>> >>
>> >> As soon as an connection to the DB is established (e.g. via rdp and
>> >> Admin
>> >> login) the normal OS user cann connect as well to the DB?!?
>> >>
>> >> Thanks and best regards,
>> >> Jochen
>> >
>> > Please try to provide the information required for someone to help you.
>> >
>> > The client connection to the database fails?
>>
>> Yes, the client connection to the database fails.
>>
>> >
>> > With what error message?
>>
>> LISTENER.LOG
>> TNS-12518: TNS:listener could not hand off client connection
>> TNS-12560: TNS:protocol adapter error occurred
>> TNS-00530: Protocol adapter error
>> 32-bit Windows Error: 2: No such file or directory
>>
>> > What is the client software application?
>>
>> A Centura based third party ERP application. In Centura I receive the
>> following message:
>>
>> connect tbbt kw/poeffel
>> ^
>> Error: 02554 SRV X54 Oracle specific error reported; more information
>> available
>>
>> And in the Centura trace file the following error message:
>>
>> 10/16/06 17:29:34 1> [oracon] login string kw(a)TBBT
>> 10/16/06 17:29:34 0> [ERROR] 2554 ORA-01019: unable to allocate memory
>> in
>> the user side
>>
>> I guess this is misleading, the server and instance works fine for
>> weeks -
>> before the Windows User rights have been changed.
>>

....

>
> We have a couple commercial programs that were written in Centura
> SQLWindows which connect to our 10g R2 (10.2.0.2) database using the
> Oracle 8.0.5, 8.1.7, and 10.2.0.1 Oracle clients. You can _probably_
> eliminate the Oracle client version as the problem.
>
> This may indicate a communication problem. Centura based applications
> require an entry in the SQL.INI file on the client computer that points
> to the correct entry in the TNSNAMES.ORA file. You should see
> something like this in the SQL.INI file under the heading [oragtwy]
> remotedbname=TBBT,@TNS:TBBT

[win32client]
clientname=den-jerfurt
SetZeroLengthStringsToNULL=ON

[win32client.ora32]
;log=C:\TEMP\oracle.log

[win32client.dll]
comdll=sqlora32

[ORAGTWY]
REMOTEDBNAME=TBBT,@TBBT.BOH.PARCOM.DE

Since the database can be access when loged in with windows admin rights the
sql.ini should be ok, even if TNS: is not explicite defined in the
connection descriptor. The sqlora32.dll if from 2003 (file releas 5.0.3,
Team Developer 2.1-PTF4-13004

> Make certain that the non-domain admin user has read permissions on the
> SQL.INI file and the Oracle install folder. Make certain that
> ORACLE_HOME\oracore\zoneinfo\timezone.dat is accessible on the client
> computer and on the server. Verify that there are not duplicate files
> on the client computer, such as OCIW32.dll, which may be for a
> different version of the Oracle client. Make certain that the NLS
> settings are correctly set. The client may be trying to create a
> temporary file in an unexpected location (maybe a client side trace) -
> FileMon should be able to spot this problem.

Meanwhile I have a brand new installed virtual machine (W2k3 Server, 10.2
client), an admin account ADMIN and an user account USER. File access rights
are Windows default and haven't been changed yet.

The files you mentioned are accessible by USER (read, execute), trace and
log files are wirtten to C:\TEMP (full access for everyone).

I have checked the file access with FileMon and still wonder what is goning
on:

When connect as USER there is * NO * access for files in
C:\oracle\product\10.2.0\client_1\network\admin\ listed * BUT * for files in
C:\oracle\product\10.2.0\client_1\RDBMS\mesg\. Obviously the error message.


I have set up access to a second database ODB2 on a different server runng
9i.

-Windows Client PC / Windows login USER Access ODB2 failed
-Windows Client PC / Windows login ADMIN Access ODB2 ok

-Windows Server / Windows login USER Access TBBT failed
-Windows Server / Windows login ADMIN Access TBBT ok

-Windows Server / Windows login ADMIN Access TBBT
AND
-Windows Client PC / Windows login USER Access ODB2 ok

Then I have closed all applications with DB connections in the ADMIN
session. When I log on as USER and simply start sqlplus with /nolog I can
connect with the Centura Application
From: Charles Hooper on 17 Oct 2006 09:01
Jochen Erfurt wrote:
> Hello Charles,
>
> thanks for you comments. Pleas see my remarks below.
>
> "Charles Hooper" <hooperc2000(a)yahoo.com> schrieb im Newsbeitrag
> news:1161035067.010459.196180(a)k70g2000cwa.googlegroups.com...
> > We have a couple commercial programs that were written in Centura
> > SQLWindows which connect to our 10g R2 (10.2.0.2) database using the
> > Oracle 8.0.5, 8.1.7, and 10.2.0.1 Oracle clients. You can _probably_
> > eliminate the Oracle client version as the problem.
> >
> > This may indicate a communication problem. Centura based applications
> > require an entry in the SQL.INI file on the client computer that points
> > to the correct entry in the TNSNAMES.ORA file. You should see
> > something like this in the SQL.INI file under the heading [oragtwy]
> > remotedbname=TBBT,@TNS:TBBT
>
> [win32client]
> clientname=den-jerfurt
> SetZeroLengthStringsToNULL=ON
>
> [win32client.ora32]
> ;log=C:\TEMP\oracle.log
>
> [win32client.dll]
> comdll=sqlora32
>
> [ORAGTWY]
> REMOTEDBNAME=TBBT,@TBBT.BOH.PARCOM.DE
>
> Since the database can be access when loged in with windows admin rights the
> sql.ini should be ok, even if TNS: is not explicite defined in the
> connection descriptor. The sqlora32.dll if from 2003 (file releas 5.0.3,
> Team Developer 2.1-PTF4-13004
>
> > Make certain that the non-domain admin user has read permissions on the
> > SQL.INI file and the Oracle install folder. Make certain that
> > ORACLE_HOME\oracore\zoneinfo\timezone.dat is accessible on the client
> > computer and on the server. Verify that there are not duplicate files
> > on the client computer, such as OCIW32.dll, which may be for a
> > different version of the Oracle client. Make certain that the NLS
> > settings are correctly set. The client may be trying to create a
> > temporary file in an unexpected location (maybe a client side trace) -
> > FileMon should be able to spot this problem.
>
> Meanwhile I have a brand new installed virtual machine (W2k3 Server, 10.2
> client), an admin account ADMIN and an user account USER. File access rights
> are Windows default and haven't been changed yet.
>
> The files you mentioned are accessible by USER (read, execute), trace and
> log files are wirtten to C:\TEMP (full access for everyone).
>
> I have checked the file access with FileMon and still wonder what is goning
> on:
>
> When connect as USER there is * NO * access for files in
> C:\oracle\product\10.2.0\client_1\network\admin\ listed * BUT * for files in
> C:\oracle\product\10.2.0\client_1\RDBMS\mesg\. Obviously the error message.
>
>
> I have set up access to a second database ODB2 on a different server runng
> 9i.
>
> -Windows Client PC / Windows login USER Access ODB2 failed
> -Windows Client PC / Windows login ADMIN Access ODB2 ok
>
> -Windows Server / Windows login USER Access TBBT failed
> -Windows Server / Windows login ADMIN Access TBBT ok
>
> -Windows Server / Windows login ADMIN Access TBBT
> AND
> -Windows Client PC / Windows login USER Access ODB2 ok
>
> Then I have closed all applications with DB connections in the ADMIN
> session. When I log on as USER and simply start sqlplus with /nolog I can
> connect with the Centura Application immediately?!?
>
>
> Thanks and best regards,
> Jochen

Here is a suggestion - the client may be trying to resolve the database
name using DNS rather than the TNSNAMES file. You can confirm this
with Ethereal/Wireshark.

In the SQL.INI file, change the ORAGTWY as follows:
[ORAGTWY]
;REMOTEDBNAME=TBBT,@TBBT.BOH.PARCOM.DE
REMOTEDBNAME=TBBT,@TNS:TBBT

Add an entry to the TNSNAMES.ORA file on the client as follows (replace
the ... with the TNSNAMES entry for the TBBT.BOH.PARCOM.DE connection:

TBBT =
(DESCRIPTION =
(ADDRESS_LIST =
....
)
)

Check the sqlnet.ora file on the client computer to see if it contains
a line such as:
TRACE_LEVEL_CLIENT = 16

If it does, the Oracle client will try to generate trace files, likely
in the same folder as the EXE files of the Centura program.

Charles Hooper
PC Support Specialist
K&M Machine-Fabricating, Inc.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: -1555-ORA-01555: snapshot too old: rollback segment number 7 with name "_SYSSMU7$" too small
Next: Oracle Chaining