Everyday, I learn something new. Or maybe I just learn again something I forgot in the meantime...
A year ago or so, I was reading throught the problems you must face when crossing the 4GB memory size. One of the question asked was: 32-bit or 64-bit? After reading the things needed to make it work on 32-bit (you must use indirect buffers, for example, thus you loose automatic SGA tuning), the answer was simple - 64-bit.
Not long before, I was asked what has to be done to use 16GB SGA on 64-bit (EM64T) Linux. Well, it's much simpler then on the 32-bit, and simple sga_target=16g will basically work.
The catch is in the word basically - the database will work, but the Linux kernel (kswapd) will have a hard time managing all the memory. Thus, you need to use huge pages (same was for 32-bit, by the way) to get optimal performance.
I'm just getting an impression, that the DBA has to know more and more about things outside the database - in this case, of OS. With ASM, about the NAS/SAN. With ...
A year ago or so, I was reading throught the problems you must face when crossing the 4GB memory size. One of the question asked was: 32-bit or 64-bit? After reading the things needed to make it work on 32-bit (you must use indirect buffers, for example, thus you loose automatic SGA tuning), the answer was simple - 64-bit.
Not long before, I was asked what has to be done to use 16GB SGA on 64-bit (EM64T) Linux. Well, it's much simpler then on the 32-bit, and simple sga_target=16g will basically work.
The catch is in the word basically - the database will work, but the Linux kernel (kswapd) will have a hard time managing all the memory. Thus, you need to use huge pages (same was for 32-bit, by the way) to get optimal performance.
I'm just getting an impression, that the DBA has to know more and more about things outside the database - in this case, of OS. With ASM, about the NAS/SAN. With ...
Comments