Depends SDE 32-bit/ 64-bit on the OS or on the RDBMS?

1472
3
Jump to solution
05-07-2012 01:08 AM
SebastianKrings
Occasional Contributor
Hi,

I have a 64-bit operating system.
I do not know wether RDBMS (MS SQL Server) will be 32-bit or 64-bit.
When installing the Arc SDE need I install 64-bit because of the OS or will this depend on the RDBMS (wether this is 32-bit or 64-bit).

Or does this not matter and I am absolutely free to install SDE in 32-bit or 64-bit. What about the compatibility to OS and RDBMS, seen from bottom-up (SDE 32-bit while OS and/or RDBMS are 64-bit) or top-down (SDE 64-bit while OS and/ or RDBMS are 32-bit).

Thanks.
0 Kudos
1 Solution

Accepted Solutions
VinceAngelo
Esri Esteemed Contributor
The operating system only matters if it restricts you from making a choice -- If the OS is 32-bit
you can *only* use 32-bit RDBMS and 32-bit ArcSDE.

If the OS is 64-bit then you can choose the bit size of the database.  Contrary to popular notions,
databases are unlikely to be significantly impacted by application word size -- the performance
of a database is keyed to I/O subsystem performance.  In many ways, 64-bit RDBMSes are
larger and slower than 32-bit (the executables are nearly twice as large) but the one advantage
they have is in memory addressing -- a 64-bit application is more likely to be able to use very
large RAM caches (>4Gb), but even the the need for this is dictated by the RAM avaliable, and
the number of instances (4 instances on 16Gb system wouldn't let you effectively use more than
~3Gb each effectively anyway, since you need to reserve at least 2-3Gb to the OS)

*Then* you come to the ArcSDE application.  Again, contrary to popular conceptions, there is
not always a significant performance benefit to having a 64-bit ArcSDE -- in fact, the last time I
tested (with 9.2sp4), 32-bit ArcSDE actually performed *faster* than 64-bit ArcSDE on a Windows
host, probably because the instructions were smaller. 

But there is an additional variable (which you have not mentioned):  Which version of ArcGIS you
are using.  ArcGIS Server 10.1 is a 64-bit application (only), while 10.0 and earlier are 32-bit (only).
In order to run a 64-bit RDBMS with a 32-bit application, you must install a 32-bit client (DLLs are
NOT interoperable).  If you're using Direct Connect with ArcGIS Server on the database host, then
you need the right client library binaries.  In many ways, it's easiest to match the ArcSDE install
to the application word size of the other ArcGIS components on the same system -- If you run
AGS on a different host, or only have Desktop clients on other hosts, then matching the RDBMS
application wordsize is a natural choice.

Since you are using SQL-Server, you don't face the further complication for Oracle users -- Oracle
client libraries are *huge*.  ArcGIS 10.0 users (and before) required a 400-600Mb 32-bit client
library in addition to the 3-4Gb 64-bit application.  ArcGIS 10.1 starts to support the Instant Client
which is much lighter weight, so there may be room on older disks for Direct Connect libraries.

If you have the time, I recommend you benchmark the performance of the various components on
your own hardware, since the actual performance is bound by the system on which it operates.

- V

View solution in original post

0 Kudos
3 Replies
VinceAngelo
Esri Esteemed Contributor
The operating system only matters if it restricts you from making a choice -- If the OS is 32-bit
you can *only* use 32-bit RDBMS and 32-bit ArcSDE.

If the OS is 64-bit then you can choose the bit size of the database.  Contrary to popular notions,
databases are unlikely to be significantly impacted by application word size -- the performance
of a database is keyed to I/O subsystem performance.  In many ways, 64-bit RDBMSes are
larger and slower than 32-bit (the executables are nearly twice as large) but the one advantage
they have is in memory addressing -- a 64-bit application is more likely to be able to use very
large RAM caches (>4Gb), but even the the need for this is dictated by the RAM avaliable, and
the number of instances (4 instances on 16Gb system wouldn't let you effectively use more than
~3Gb each effectively anyway, since you need to reserve at least 2-3Gb to the OS)

*Then* you come to the ArcSDE application.  Again, contrary to popular conceptions, there is
not always a significant performance benefit to having a 64-bit ArcSDE -- in fact, the last time I
tested (with 9.2sp4), 32-bit ArcSDE actually performed *faster* than 64-bit ArcSDE on a Windows
host, probably because the instructions were smaller. 

But there is an additional variable (which you have not mentioned):  Which version of ArcGIS you
are using.  ArcGIS Server 10.1 is a 64-bit application (only), while 10.0 and earlier are 32-bit (only).
In order to run a 64-bit RDBMS with a 32-bit application, you must install a 32-bit client (DLLs are
NOT interoperable).  If you're using Direct Connect with ArcGIS Server on the database host, then
you need the right client library binaries.  In many ways, it's easiest to match the ArcSDE install
to the application word size of the other ArcGIS components on the same system -- If you run
AGS on a different host, or only have Desktop clients on other hosts, then matching the RDBMS
application wordsize is a natural choice.

Since you are using SQL-Server, you don't face the further complication for Oracle users -- Oracle
client libraries are *huge*.  ArcGIS 10.0 users (and before) required a 400-600Mb 32-bit client
library in addition to the 3-4Gb 64-bit application.  ArcGIS 10.1 starts to support the Instant Client
which is much lighter weight, so there may be room on older disks for Direct Connect libraries.

If you have the time, I recommend you benchmark the performance of the various components on
your own hardware, since the actual performance is bound by the system on which it operates.

- V
0 Kudos
GastonIzaguirre
New Contributor III

Hi Vince,

I've read many of your answers to issues reported by users, but I have not yet been able to solve the two problems I have.

  • Direct Connections from ArcCatalog 10.0 to Oracle 10g R2.
  • Geodatabase Upgrade.

I will describe the my situation.

I have two servers:

SERVER 1
OS: Windows 2008 (64-bit)
Oracle RDBMS: 10.2.0.4 (64-bit)
Oracle Client: 10.2.0.4 (32-bit)
Oracle Client ODAC: 11.2.0.2 (32-bit)
Oracle Gateway: 11.2.0.1 (64-bit)
ArcGIS Server: 10.0 SP1 (32-bit)
ArcSDE: 10.0 SP1 (64-bit)
ArcGIS Desktop: 10.0 SP5 (32-bit)
Enterprise geodatabases: 3

SERVER 2
OS: Windows 2008 R2 (64-bit)
Oracle RDBMS: 10.2.0.5 (64-bit)
Oracle Client: 10.2.0.5 (64-bit)
ArcGIS Server: 10.0 SP5 (32-bit)
ArcSDE: 10.0 SP5 (64-bit)
ArcGIS Desktop: 10.0 SP5 (32-bit)
Enterprise geodatabases: 2

From the SERVER 1, using ArcCatalog, I can establish direct connections to the 3 local geodatabases and also to the 2 geodatabases on the SERVER 2.

I have also been able to upgrade the 3 local geodatabases. But from SERVER 1 I could not update the 2 geodatabases on SERVER 2, since I get the following error:

"Connected RDBMS instance is not setup for ST_GEOMETRY configuration.
[Unable to determine current version of ST_SHAPELIB The latest ST_GEOMETRY and dependent libraries need to be copied to the correct software location. Please consult ArcSDE for Oracle Installation Guide for further details.]"

From the SERVER 2, using ArcCatalog, I can not establish direct connections to any geodatabase, when I try it I get the error:

"Failed to connect the specified server. Server library could not be loaded."

I think the problems are related to the oracle client installed on SERVER 2, which is 64-bit.

If I install a 32-bit oracle client can I solve both problems?
Or are they due to different causes?
What would be the correct configuration of SERVER 2?

Thank you in advance.

Regards,

Gaston.

0 Kudos
VinceAngelo
Esri Esteemed Contributor

This is a response to really ancient post.  ArcGIS Server has been 64-bit for so long that the last 32-bit incarnation has been retired from support for two and a half years. All of your products are ancient, and fairly dangerous to operate, since the volume of known security flaws is significant. I can't in good faith make any recommendations to utilize such flawed configurations.