Problem:
When migrating a database from an older Solaris database server to a new Solaris T3/T4 series database server, SGA_Target has to be increased from 350MB t0 900MB to have the database started up. Otherwise ORA-04031 error would occur.
After spending sometime researching, the following Oracle Support article explains the issue and gives a workaround.
Reference: ORA-00821 ORA-01034 ORA-27101, SGA_target need to be increased [ID 815426.1]
Goal
Migrated
a database server from a server with 8 CPU's to a server with 128 (virtual)
CPU's - that is, 2 CPU's, each with 8 cores which each handled 8 threads =
2x8x8 = 128.
So Solaris (on SPARC T series) is presenting Oracle with 128 CPU's. This makes Oracle adjust it's memory demands upwards, meaning that before the databases can ran fine with 320 MB of ram (sga_target) now needs to have up around 800-900 MB of RAM?
Is there anyway to minimize the memory usage?
Calculating the sga_target should consider the following:
The calculation for min cache size = max (number of CPUs, number of processor groups) * max (granule size, 4MB)
So the SGA size will mainly depend on CPU_COUNT.
Bug 8316255 was filed for this issue and initially closed as 'Not a Bug' with the comments:
"CPU_COUNT should not be changed . This is not a bug.
Reducing CPU_COUNT has side effects due to the fact that the per cpu power of CMT may not be sufficient to sustain high load ( e.g. cache fusion messages ).
Also, some of the dependent parameters such as gc latches would be underconfigured ".
Currently, a fix has been produced which added the notion of the raw cpu threads and effective cpu threads.
This fix is only available in the 11.2.0.3 Bundle Patch 1 for Exadata Database and will be included in 12.1.
Please refer to:
Note 8316255.8 - Bug 8316255 - Wrong discovery of number of CPUs in SPARC T series.
Note 13343057.8 - Bug 13343057 - 11.2.0.3 Bundle Patch 1 for Exadata Database
For other systems, a way of reducing memory needs would be to set a manual value for DB_CACHE_SIZE (which depends on CPU_COUNT) and keep the old value of SGA_TARGET or not using ASMM (not using SGA_TARGET).
Reference: ORA-00821 ORA-01034 ORA-27101, SGA_target need to be increased [ID 815426.1]
When migrating a database from an older Solaris database server to a new Solaris T3/T4 series database server, SGA_Target has to be increased from 350MB t0 900MB to have the database started up. Otherwise ORA-04031 error would occur.
After spending sometime researching, the following Oracle Support article explains the issue and gives a workaround.
Reference: ORA-00821 ORA-01034 ORA-27101, SGA_target need to be increased [ID 815426.1]
Goal
So Solaris (on SPARC T series) is presenting Oracle with 128 CPU's. This makes Oracle adjust it's memory demands upwards, meaning that before the databases can ran fine with 320 MB of ram (sga_target) now needs to have up around 800-900 MB of RAM?
Is there anyway to minimize the memory usage?
Calculating the sga_target should consider the following:
The calculation for min cache size = max (number of CPUs, number of processor groups) * max (granule size, 4MB)
So the SGA size will mainly depend on CPU_COUNT.
Bug 8316255 was filed for this issue and initially closed as 'Not a Bug' with the comments:
"CPU_COUNT should not be changed . This is not a bug.
Reducing CPU_COUNT has side effects due to the fact that the per cpu power of CMT may not be sufficient to sustain high load ( e.g. cache fusion messages ).
Also, some of the dependent parameters such as gc latches would be underconfigured ".
Currently, a fix has been produced which added the notion of the raw cpu threads and effective cpu threads.
This fix is only available in the 11.2.0.3 Bundle Patch 1 for Exadata Database and will be included in 12.1.
Please refer to:
Note 8316255.8 - Bug 8316255 - Wrong discovery of number of CPUs in SPARC T series.
Note 13343057.8 - Bug 13343057 - 11.2.0.3 Bundle Patch 1 for Exadata Database
For other systems, a way of reducing memory needs would be to set a manual value for DB_CACHE_SIZE (which depends on CPU_COUNT) and keep the old value of SGA_TARGET or not using ASMM (not using SGA_TARGET).
Reference: ORA-00821 ORA-01034 ORA-27101, SGA_target need to be increased [ID 815426.1]
The workaround did not work.
ReplyDeleteDB_CACHE_SIZE also depends on CPU_COUNT. When database starts, it is automatically changed to over 500MB even it is set to be 50MB in the init.ora file. over 1GB memory is required to start the database.