Can't connect to Ora 10g w/ 3-tier conn from AGS Svr 10 SP1

3618
18
03-10-2011 09:34 PM
ChristinaKepler
New Contributor
This thread was posted to the 'AGS General' forum, but thought I'd re-post here since not getting a solid answer...

We have AGS 10 SP1 running on Windows Server 2003, and Oracle 10g (10.2.0.4) on a remote server (also Server 2003).  We can connect from AGS using a direct connection (have the Oracle client s/w installed, etc.)  But when attempting to connect with a service-based 3-tier connection, we get a "Error 1053: The service did not respond to the start or control request in a timely fashion" error.

The Windows Event Viewer has the following two simultaneous entries:
1. Timeout (30000 milliseconds) waiting for the ArcSde Service(esri_sde_ora2) service to connect.

2. The ArcSde Service(esri_sde_ora2) service failed to start due to the following error:
The service did not respond to the start or control request in a timely fashion.

Oddly, my sde_esri_sde_ora2.log has not been logged to since Jan. 24th of this year, even though I just tried to start the service and the errors were logged to the Windows event log.

It's also worth noting that the errors are reported immediately after trying to start the service, so a 30 second timeout error seems strange.

The executable that the service is attempting to start is 'C:\ESRI\ArcGIS\ArcSDE\ora10gexe\\bin\giomgr.exe'. (Apparently the double backslash '\\' has no adverse affects and the system can correctly resolve the path to the exe). If I run that from the command line, it throws the 'OCI.dll not found' error.

I've verified that my ORACLE_HOME env var is set to the correct location and that ORACLE_HOME\bin is in my Path env var.  Also the LOCAL var is set correctly in dbinit.sde, etc.

I've followed the instructions for Installing Oracle and ArcSDE on separate servers and Creating an ArcSDE service from a remote Windows server, but when I try to start the remote service using the instructions at Starting a remote ArcSDE service on Windows, I immediately get the error:

Error: Access denied when starting esri_sde_ora2 instance on ora2.
Operation Failed, Unable to start iomgr.

My questions are:
1. What is the <DB_Admin_password> noted in the sdemon commands? Is that the password for the sde user on the Oracle server? Or the 'sys' Oracle user? Or something else?

2. When running the command to create a service on the remote Oracle server according to the instructions at Creating an ArcSDE service from a remote Windows server, it creates a service locally on the SDE server. Is it also creating a service on the remote Oracle server??

3. What should I have our Oracle admin look for on the Oracle server to ensure that the service was created successfully on that server?  Are there any tests I can try outside of a service connection to verify that the installation steps were successful?

4. When creating the remote service on the Oracke server, there is no parameter to define which port to use. If I already have a SDE service running on port 5151 on the local machine, I'd like to use a different port. How is it possible to define the port on the remote machine? The 'sdeservice -o create' command does not seem to have a parameter for port. The instructions at Starting a remote ArcSDE service on Windows indicate that the port number must be entered into the Windows services file on BOTH the local and remote servers.  How do I keep these in sync between the local and remote servers?
0 Kudos
18 Replies
VinceAngelo
Esri Esteemed Contributor
1) The 'DB_Admin_password' is the SDE user password

2) No.

3) In a "Remote Server" configuration, no ArcSDE service is created on the Oracle server.
The DBA can help you make sure that your client install is correct (it should be the same
release as the server [10.2.0.4, in this case]), that your tnsnames.ora is correct (via 'tnsping'),
and that you can successfully connect to the server via SQL*Plus after setting the LOCAL
environment variable (the dbinit.sde should have the same LOCAL [not ORACLE_SID] contents).

4) There certainly is a way to define which port to use -- the "-i <service>" parameter
of 'sdeservice'.  You must edit the %SystemRoot%\system32\drivers\etc\services file
to map the mnemonic to a port number.  It's not required that all hosts in your network
have the same services file, but it is a good idea.  I typically run 15-20 different services
on my networks at home, office and client sites; it just takes a little effort to set up a
naming convention appropriate for the network, then copy/paste the 5151->???? entries
into the services file on each host.

30-sec connection timeouts are generally due to a bad hostname/port combination,
so you want to be sure your LOCAL is pointing to a correct tnsnames.ora entry.

It would probably be best to start an incident with Tech Support so they can walk you
through this configuration (it's tricky the first time, but by the third time you won't even
need the documentation). 

- V
0 Kudos
ChristinaKepler
New Contributor
Thanks for the help and quick reply Vince -- much appreciated.

I have to respectfully decline to open an incident with tech support since we are a development shop (EDN license only) and pay a premium for each ticket that we open.  So we have to preserve those incidents for dire needs only.  This issue seems like one that should be solvable with trial and error (and forums 🙂 since the documentation is falling short.

I've tried recreating the service by passing the '-i <port>' since, as you noted, the service name and port # are interchangeable:

sdeservice -o create -p memorial -d ORACLE10G,ORA2 -n -i 5157

I've verified that the %SystemRoot%\system32\drivers\etc\services file has the correct entry:

esri_sde_ora2 5157/tcp #ArcSDE for Oracle

and I corrected the dbinit.sde file after the sdeservice command was run so that the ORACLE_SID entry was commented and the LOCAL entry was added:
___________________________________________________
# Oracle SID for service esri_sde_ora2.
# set ORACLE_SID=ORA2
set LOCAL=ORA2
set ORACLE_HOME=C:\oracle\product\10.2.0\client_1
set SDEHOME=C:\ESRI\ArcGIS\ArcSDE\ora10gexe
___________________________________________________
My Oracle Net service name is 'ORA2' and I can connect via SQLPlus and a SDE direct connection.

When attempting to start the SDE service with the sdemon command:

sdemon -o start -i 5157

I get the error:

Error starting esri_sde_ora2 service(0)
Could not start ArcSDE -- Check Network, $SDEHOME disk, DBMS settings and dbinit.sde.

One thing that's confusing to me is that if there is no SDE service created on the remote Oracle server, why is it necessary to have an entry in the services file on that machine that corresponds to the entry on the ArcSDE server?   Could that be why the error is occurring?
0 Kudos
VinceAngelo
Esri Esteemed Contributor
It *isn't* necessary that the Oracle server have a services entry, just good practice
to prevent port collision.

It's probably a mistake to treat service names and ports as if they were interchangable,
especially during service creation (it's often true on the client side, but not on the server). 
Try using the service mnemonic for both 'sdeservice -o create' and  'sdemon -o start'.

- V
0 Kudos
ChristinaKepler
New Contributor
Thanks for your continued assistance with this Vince.

I tried using the mnemonic for both 'sdeservice -o create' and 'sdemon -o start':

sdeservice -o create -p <password> -d ORACLE10G,ORA2 -n -i esri_sde_ora2
sdemon -o start -i esri_sde_ora2 -p <password>

But am getting the same error:

Error starting esri_sde_ora2 service(0)
Could not start ArcSDE -- Check Network, $SDEHOME disk, DBMS settings and dbinit.sde.

I recalled reading somewhere that a udp entry is also required in the Windows services file, so I made that change as well on the SDE server and had our Oracle admin make the change on the Oracle server (also made to SDE services.sde file, but not sure it matters):

esri_sde_ora2 5157/tcp #ArcSDE for Oracle
esri_sde_ora2 5157/udp #ArcSDE for Oracle

Still getting the same error.

Also, not sure if it matters but our Oracle server is Windows 2008 R2, not Windows 2003 as I originally reported.  Our SDE server is Windows 2003 SP2 x64.
0 Kudos
VinceAngelo
Esri Esteemed Contributor
UDP is not used in the ArcSDE client/server connection protocol.

Is your Oracle client 32-bit or 64-bit? Is your ArcSDE install 32-bit or 64-bit?

Does the SDEHOME reported by sdeservice -o list correspond to the ORA2 SDEHOME?

- V
0 Kudos
ChristinaKepler
New Contributor

Is your Oracle client 32-bit or 64-bit? Is your ArcSDE install 32-bit or 64-bit?

Does the SDEHOME reported by sdeservice -o list correspond to the ORA2 SDEHOME?


ArcSDE install is v10 SP1 64-bit.  Oracle client is 32-bit (v10.2.0.3) which is the only version that enabled a direct connection and the version that I needed to install according to this FAQ.  Version 10.2.0.3 of the client is the only 32-bit version that I could find to download on the Oracle Web site (note that Oracle server is v10.2.0.4). 

SDEHOME referenced by 'sdeservice -o list' reports 'C:\ESRI\ArcGIS\ArcSDE\ora10gexe\', which is correct.  Not sure what is meant by 'ORA2 SDEHOME' -- as specified where?  SDEHOME env var on local SDE machine *and* SDEHOME in %SDEHOME%\etc\dbinit.sde both match though.
0 Kudos
VinceAngelo
Esri Esteemed Contributor
64-bit ArcSDE cannot function with a 32-bit Client (the DLL search fails when
a DLL with the right name but wrong wordsize is found).

It you have a 32-bit Oracle Client for 32-bit ArcGIS, you should be using a
32-bit ArcSDE Server. This isn't a bad thing -- In my testing, 64-bit ArcSDE
did not provide a performance benefit over 32-bit ArcSDE on either 64-bit
Windows 2003 Server or RedHat Linux 4/5 (x64).

The one time I attempted to have both 32-bit and 64-bit Oracle client installs
with both 32-bit and 64-bit ArcSDEs on an x64 2003 host, I toasted my registry
so badly I had to have the virtual machine re-imaged.

Note that ArcGIS 10.1 will be mostly 64-bit, so at that point you'll have more
reason to run 64-bit ArcSDE with a 64-bit Oracle Client.

- V

BTW: You can/should apply the 10.2.0.4 patchset to your 10.2.0.3 client, since
Vince's Second Law of Compatibility says "In a client-server architecture, always
run your clients at least even to the server release" (a little ahead is okay, but
behind is asking for trouble).

PS: If you have multiple ArcSDE application servers running, you really should
have multiple SDEHOME locations.
0 Kudos
ChristinaKepler
New Contributor
Vince:

Thanks so much for bearing with me on this...

A few things:

- If the 64-bit ArcSDE can't function w/ a 32-bit Oracle client, I'm confused as to why it's the only configuration that worked for direct connections (?).

- I'll gladly uninstall the 64-bit ArcSDE and install the 32-bit if that will fix my problems.  However will that be compatible with the installation of ArcGIS Server on the same machine?  It's unclear to me if the ArcGIS Server installation is 32-bit or 64-bit (the installer doesn't differentiate like the SDE installer does, and there doesn't seem to be an easy way to figure it out).  Do you think the best course of action at this point is to uninstall ORA SDE 64 and install ORA SDE 32?  (What's more, if I have SDE 64 for SQL Server on the same machine, are there any shared DLLs that would hose my installation?  If so, then I should also uninstall SQL SDE 64 and install SQL SDE 32?)

- RE: " Does the SDEHOME reported by sdeservice -o list correspond to the ORA2 SDEHOME?
. . .
If you have multiple ArcSDE application servers running, you really should
have multiple SDEHOME locations."

Not sure what is meant by 'ORA2 SDEHOME' -- as specified where?

I think I'm all set, but please let me know if I'm not:
>sdeservice -o list

SDE service Information
--------------------------------------------------------------------
Error querying 5157 service
RDBMS:                  Oracle
Name:                   ArcSde Service(5157)
SDEHOME:                C:\ESRI\ArcGIS\ArcSDE\ora10gexe\
Version:                10.0
Status:

RDBMS:                  Oracle
Name:                   ArcSde Service(esri_sde_ora2)
SDEHOME:                C:\ESRI\ArcGIS\ArcSDE\ora10gexe\
Version:                10.0
Status:                 SERVICE_STOPPED

RDBMS:                  SQLServer
Name:                   ArcSde Service(esri_sde_sqlsvr)
SDEHOME:                C:\ESRI\ArcGIS\ArcSDE\sqlexe
Datasource:             GIS4
SDE_DBA_USER:           sde
Admin_database:         sde
Version:                10.0
Status:                 SERVICE_RUNNING

That instance of 'service(5157)' is certainly curious -- it doesn't show up in my Windows Services.

- What's Vince's *First* Law of Compatibility?  😉

Thanks again.
0 Kudos
ChristinaKepler
New Contributor
Two things to add to previous thread (though would appreciate responses to those as well):

- I uninstalled the ORA SDE 64 bit and installed ORA SDE 32 and it installed fine but when attempting to run post-install, got a 'ArcSdeSetupOracle10g.exe - Entry Point Not Found' dialog that said, "The procedure entry point SgShapeGetParametricType could not be loaded in the dynamic link library sg.dll".

Ugh.

I made sure the 64-bit exes were all removed before installing the 32 bit version, and my SDEHOME is correctly set to C:\ESRI\ArcGIS\ArcSDE\ora10gexe\.


- Maybe I can avoid the whole trying to get a 3-tier service-based connection to work if I can just register a spatial view after creating one w/ SQL (i.e. w/o having to run the 'sdelayer �??o register' command).
0 Kudos