Does anyone know what the hold up is on certifying Virtual Center 2.5 and Oracle 10.2.0.3 64bit? Was looking to upgrade to 3.5/2.5, but we only run 64bit Oracle in our Production environment.
*
In this document
http://www.vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_installation_guide.pdf
all supported Databases are listed.... (Page 19)
*
Oracle 10g Standard Release 2 (10.2.0.1.0) Oracle 10g Enterprise Release 2 (10.2.0.1.0)
First apply patch 10.2.0.3.0 to the client and server. Then apply patch 5699495 to the client.
Regradless of 32 or 64 bit installation or platform its supported. This is because your SQL command returns the same values redardless of the underlying hard and software architecture. -> means .... VC even use the same scripts... if it is 9i or 10g.
But please read the release notes too... There are some hints how to configure the schema.... (priviliges because CONNECT ROLE changed and so on)
Regards,
I'm already running 10.2.0.3 in my Virtual Center 2.x environment and it's fully patched. While I agree that 64bit "should" work, there's obviously a reason that the compatibility matrix below has "NO" for 10.2.0.3 64bit and Virtual Center 2.5. My question is when will it officially be supported by VMware, my company does not run unspported configurations for critical applications. Thanks.
See Page 5 - Table 6 (continued)
http://www.vmware.com/pdf//vi3_35/esx_3/r35/vi3_35_25_compat_matrix.pdf
You are absolute right. No support for 64bit atm. I'll find out if 64bit will be supported in the future and post the answere here.
Regards,
Hi Divintas,
Did you have news about 64bit support ?
Thanks
The only response I can get from VMware Support is that they "hope" to support 64 bit Oracle in the future releases, not very promising, so I'm probably going to be moving over to SQL Server in the next month or so if nothing comes out, seems like this is their primary DB platform for VC anyway.
This may be one reason VM Ware doesn't want to support 64-bit just yet:
When 32-bit Oracle is acceptable
You might want to stay on a 32-bit server if any of these conditions are true:
- Linear processing: You do not need multiple-CPU SMP processing (Oracle parallel query) for large-table, full-table scans.
- No need for large data buffers: If you do not have large working sets (e.g., an OLTP database) then 32-bit may be the right choice.
- External bottleneck: A 32-bit architecture is fine if your bottleneck is not in the Oracle database. In an ERP system, the bottleneck may be in the app servers, Web caches, or network, and a faster database will not help.
- High buffer invalidations: If your application performs frequent data purges, data truncations or makes high-volume use of temporary tables, then you may not find large RAM regions suitable.
- Not computationally intensive: If your bottleneck is in the network or disk I/O, then the faster 64-bit CPUs will not improve your overall performance.
While a 64-bit server is not a panacea, there are several well-documented reasons for moving to a 64-bit server. If any of the following conditions are true, then you may want to consider a 64-bit solution:
- High transactions processing rates: Systems with more than 200 disk I/O's per second may see dramatic improvement in speed and scalability. By caching large amounts of data, disk I/O is reduced and performance skyrockets.
- Declining performance: As systems grow, the 32-bit limitations prevent continued growth.
- Anticipating rapid growth: For systems that require uninterrupted growth and scalability, the 64-bit architecture allows almost infinite scalability. Many large ERP systems have been able to scale successfully on Windows 64 platforms.
- Computationally-intensive system: If your Oracle database is CPU-bound or if you perform lots of parallel full-table scans, then the faster processors in a 64-bit architecture are very appealing.
This document was generated from the following thread: Virtual Center 2.5 and Oracle 10.2.0.3 (64bit) compatibility