Oracle Point, Oracle Life.

Most Popular Posts

June 24, 2008

Materialized View Log internal

Filed under: OraclePoint — R.Wang @ 6:46 pm

In order to perform cleanup before oracle database upgrade, we found that there are tens of materialized view log tables existing in our production database. Those tables prefixing with MLOG$ were created for materialized view refresh. When DML changes are made to master table data, Oracle Database stores rows describing those changes in the materialized view log table and then uses the materialized view log table to refresh materialized views based on the master table. This process is called incremental or fast refresh. Without a materialized view log, Oracle Database must re-execute the materialized view query to refresh the materialized view. This process is called a complete refresh. Usually, a fast refresh takes less time than a complete refresh.

In our case, we would like to eliminate this materialized view logic. Therefore, we need to issue “drop MATERIALIZED VIEW LOG on table;” to drop the relationship with master table. Actually, the above command does two things:

  1. drop the internal trigger on base table (check view dba_internal_triggers)
  2. drop the materialized view log table

Issuing simple drop table command doesn’t work because the internal trigger is still existing and any DML activity will raise the error because the materialized view log table is missing.

bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark

Popularity: 5% [?]

Tags:

June 16, 2008

Windows Memory Management with term description

Filed under: Technology Misc — R.Wang @ 2:07 pm

My preceding post title "Oracle Database 11g Architecture on Windows" talked about key points about oracle 11g architecture on windows. In that post, some key windows memory management points were included, such as 4GB RAM Tuning (4GT), Very Large Memory (VLM), and Large Pages. In this post, I’m trying to create complete description and reference of above terms about memory management on windows. 1. 4GB RAM Tuning (4GT) - Windows allocates the lower half of the 4GB address space (from 0×00000000 to 0×7FFFFFFF) to processes for their own unique private storage, and reserves the other half (from 0×80000000 to 0xFFFFFFFF) for the Operating System’s use.This address space translates into 4GB of virtual memory - no more, and no less.

  • Reference: Memory Management 101 — covers the basics of 32-bit Memory architecture and the difference between Kernel and User mode memory
  • Reference: Memory Management - Demystifying /3GB — On 32-bit versions of Windows, the /3GB parameter enables 4-gigabyte (GB) random access memory (RAM) Tuning, a feature that enlarges the user-mode virtual address space to 3 GB and restricts the kernel-mode components to the remaining 1 GB. /3GB boot-time option to allow the user mode address space to grow to 3GB and it’s available at Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows XP SP2 and later and all versions of Windows Server 2003
  • Reference: The /PAE (Physical Address Extension) parameter — PAE is an Intel-provided memory address extension that enables support of greater than 4 GB of physical memory for most 32-bit (IA-32) Intel Pentium Pro and later platforms.PAE is supported only on 32-bit versions of the Windows operating system. 64-bit versions of Windows do not support PAE.
  • Reference: 4-Gigabyte Tuning – How to enable and use 4GT on windows platforms

2. Very Large Memory (VLM) — Specifically, Oracle Database uses Address Windowing Extensions (AWE) built into Windows 2000, Windows 2003, and Windows XP to access more than 4 GB of RAM.

  • Address Windowing Extensions (AWE) — Address Windowing Extensions (AWE) is a set of extensions that allows an application to quickly manipulate physical memory greater than 4GB. AWE solves this problem by allowing applications to directly address huge amounts of memory while continuing to use 32-bit pointers. AWE allows applications to have data caches larger than 4GB (where sufficient physical memory is present). AWE uses physical nonpaged memory and window views of various portions of this physical memory within a 32-bit virtual address space.

3. Large Pages — Large Page support is a feature that provides a performance boost for memory-intensive database instances on both 32-bit and 64-bit Windows Server 2003. Large-page support enables server applications to establish large-page memory regions, which is particularly useful on 64-bit Windows. Each large-page translation uses a single translation buffer inside the CPU. The size of this buffer is typically three orders of magnitude larger than the native page size; this increases the efficiency of the translation buffer, which can increase performance for frequently accessed memory.

bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark bookmark

Popularity: 5% [?]

Tags:

Page: 1 | 2 | 3 | 4 | 5
 

Windows Live Translator:

Google