Author Archives: alesk
The Log_buffer parameter cannot be changed In 10g R2
According to Oracle10g R2 Reference Guide LOG_BUFFER parameter is not modifiable any more. This is correct.
Guide is also saying that the default value is: 512 KB or 128 KB * CPU_COUNT, whichever is greater
This information is wrong (and the same documentation error is present in 11g R1 Reference Guide) .
According to Metalink note 351857.1 “The Log_buffer Cannot be Changed In 10g R2”, they changed the way how log buffer is allocated. Oracle 10g R2 combines fixed SGA and redo log buffer. Free space that is left after fixed sized SGA is allocated in the memory granule, Oracle dedicates to LOG_BUFFER.
This is why on all our systems log_buffer is around 14MB (our granule is 16MB, according to _ksmg_granule_size parameter, and fixed size SGA is around 2MB).
SQL> show release release 1002000300 SQL> show sga Total System Global Area 9697230848 bytes Fixed Size 2070776 bytes Variable Size 1291847432 bytes Database Buffers 8388608000 bytes Redo Buffers 14704640 bytes
I think this is a good move by Oracle. A lot of awkward “rules of thumb” for LOG_BUFFER sizing are now obsolete.
Oracle11g OUI – default Oracle base location
I’m not sure who is to blame – it must be the new kids on the block at Oracle HQ….
What do you think about 11g new defaults for Oracle base on Windows?
They propose (silly in it’s own way!) default Oracle base directory with this explanation:
Specify a base location for storing all Oracle software and configuration-related files. This location is the
Oracle base directory. Create one Oracle Base for each operating system user. By default, software and configuration files are installed by version and database name in the Oracle Base directory.
Oracle Base: D:\app\scott
Software Location
Name:
Path: D:\apps\scott\product\11.1.0\db_1
What is wrong with simple, yet universally understandable Oracle base, such as D:\ORACLE, for example. Why APPS, why OS user name?
It must be that someone is smoking the wrong stuff.
Regards,
Ales
How much memory is available to 32-bit applications running on Windows x64?
A recent post on a dba-village.com forum triggered this topic. The forum member mentioned that one of the drawback of running 32-bit Oracle server on Windows x64 is, among other things, the limitation of total 3GB of memory per process, as it was the case in old-days, running Windows 2000/2003 with /3GB switch in boot.ini. This is not correct.
Well, Microsoft replaced venerable WOW32 with WOW64 in Windows x64. WOW32 was designed to run 16-bit applications on 32-bit OS and WOW64 that ships with Windows x64 was designed to support running 32-bit applications on Windows x64. (Btw. you can’t run 16-bit applications on Windows x64 anymore)
So, the question is, how does WOW64 handle memory for 32-bit applications? Well, it emulates the old environment, with one benefit. By default, the 32-bit application will have 2GB available virtual memory and if it’s compiled with /LARGERMEMORYAWARE flag, then the process can address 4GB of virtual memory. For example, oracle.exe (32bit) is compiled with such flag – that’s why it could use extra memory given by /3GB switch via boot.ini in the old days and that’s why it can address full 4GB within WOW64! That’s 1GB more compared to the very same process running natively on 32-bit Windows OS/CPU.
Two recommended articles:
- Windows Server 2003 x64 Editions, Deployment Scenarios by MVP, Charlie Russel
- Introducing Microsoft Windows Server 2003 x64 Editions for the Intel EM64T Platform by Ranjith Purush and Chip Webb
Windows search path
The search path for DLL’s before Windows XP SP1 and Windows Server 2003 was:
- search in directory of executable
- search in working directory
- search in Windows system directory (SYSTEM32 as well as SYSTEM!)
- search in Windows directory
- search in path defined by variable %PATH%
Search sequence changed in windows XP SP1 and Windows 2003, a quote from article by Michael Howard, “Development Impacts of Security Changes in Windows Server 2003”:
QUOTE:
DLL Search Order Has Changed
No longer is the current directory searched first when loading DLLs! This change was also made in Windows XP SP1. The default behavior now is to look in all the system locations first, then the current directory, and finally any user-defined paths. This will have an impact on your code if you install a DLL in the application's directory because Windows Server 2003 no longer loads the 'local' DLL if a DLL of the same name is in the system directory. A common example is if an application won't run with a specific version of a DLL, an older version is installed that does work in the application directory. This scenario will fail in Windows Server 2003.
The reason this change was made was to mitigate some kinds of trojaning attacks. An attacker may be able to sneak a bad DLL into your application directory or a directory that has files associated with your application. The DLL search order change removes this attack vector.
The SetDllDirectory function, also available in Windows XP SP1, modifies the search path used to locate DLLs for the application and affects all subsequent calls to the LoadLibrary and LoadLibraryEx functions by the application.
This fact can have a major consequence when troubleshooting applications that depends on common libraries (such as msvcr*.dll). If safe search order is turned ON, the search sequence is: 1, 3, 4, 2, 5 from the list above.
My first thought (of course;-) was: how to disable safe search order feature?
According to article Dynamic-Link Library Search Order, all you need to do is, to add a registry value:
HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode and set it to 0.
Export error after applying CPUOCT2007
After you apply CPUOCT2007 (Patch 12) on top of Oracle 10.2.0.3 you’ll get error during full database export, such as the one shown below:
. about to export SYSTEM's tables via Direct Path ... . . exporting table DEF$_AQCALL EXP-00008: ORACLE error 6550 encountered ORA-06550: line 1, column 18: PLS-00201: identifier 'SYS.DBMS_DEFER_IMPORT_INTERNAL' must be declared ORA-06550: line 1, column 7: PL/SQL: Statement ignored ORA-06512: at "SYS.DBMS_SYS_SQL", line 1204 ORA-06512: at "SYS.DBMS_SQL", line 323 ORA-06512: at "SYS.DBMS_EXPORT_EXTENSION", line 97 ORA-06512: at "SYS.DBMS_EXPORT_EXTENSION", line 126 ORA-06512: at line 1
Bug is documented in Metalink note:
464672.1 “ORA-06512 SYS.DBMS_EXPORT_EXTENSION And PLS-00201 SYS.DBMS_DEFER_IMPORT_INTERNAL in 11g Export Or After OCTCPU2007”
The recommended workaround is to grant the missing privileges:
GRANT EXECUTE ON SYS.DBMS_DEFER_IMPORT_INTERNAL TO user_doing_export; GRANT EXECUTE ON SYS.DBMS_EXPORT_EXTENSION TO user_doing_export;
By the way, a short tip: we’re running full export with rows=n on a daily basis. Why? Because we’re keeping those dumps long-term, if anyone wants to get some DDL definition or PL/SQL procedure/package from the past, we can extract the source with the excellent free utility DDL Wizard. DDL Wizard can parse empty (rows=n) export dump files.
dbaportal.eu 