DBA ORACLE

Automatisation de la bascule de clients

noreply@blogger.com (DBA ORACLE) — Wed, 07 Jul 2010 17:40:00 +0000

Automatisation de la bascule de clients
La capacité à réaliser rapidement une bascule de base de données n'est que la première des
conditions de la haute disponibilité. Les applications doivent aussi pouvoir se déconnecter
rapidement d'une base de données principale défaillante, puis se reconnecter rapidement à la
nouvelle base Primaire.
Une bascule de clients efficace dans un contexte Data Guard comporte trois composants :
• Bascule de base de données rapide
• Démarrage rapide des services de base de données sur la nouvelle base Primaire
• Notification rapide des clients et reconnexion rapide à la nouvelle base Primaire
Dans les versions précédentes d'Oracle, il fallait un ou plusieurs déclencheurs de base de données
écrit par l'utilisateur pour automatiser la bascule de clients, en fonction de la configuration.
Data Guard 11g Release 2 simplifie beaucoup la configuration ; les déclencheurs écrits par
l'utilisateur ne sont plus nécessaires pour automatiser la bascule de clients. Les changements de
rôles gérés par l'interface Data Guard Broker peuvent permettre une bascule automatique de la
base de données,

Fast-Start Failover

noreply@blogger.com (DBA ORACLE) — Wed, 07 Jul 2010 17:40:00 +0000

Fast-Start Failover
Fast-Start Failover permet à Data Guard d'effectuer une bascule (FAILOVER) automatique vers
une base de données de secours préalablement choisie sans qu'aucune intervention manuelle ne
soit requise pour lancer cette opération. Un processus de contrôle (Data Guard Observer)
surveille en continu l'état d'une configuration Fast-Start Failover. Si l'observateur et la base de
secours perdent simultanément la connexion avec la base principale, l'observateur tente de se
reconnecter à la base principale pendant une durée configurable, avant de lancer un basculement
Fast-Start Failover. Fast-Start Failover est conçu pour s'assurer que sur ses trois membres (la base
Primaire, la base de secours et l'observateur) au moins deux sont en accord sur les changements
d'états importants pour éviter tout scénario de dissociation (« split-brain »). Une fois la base
principale réparée et montée, elle doit établir une connexion avec le processus de l'observateur
avant de pouvoir s'ouvrir. Une fois ouverte, elle est informée qu'une bascule (FAILOVER) s'est
déjà produite et la base principale d'origine est automatiquement rétablie en tant que base de
secours de la nouvelle base Primaire. L'architecture simple mais élégante de Fast-Start Failover en
fait un excellent choix lorsque la haute disponibilité et la protection des données sont requises
simultanément

Gestion d'une configuration Data Guard

noreply@blogger.com (DBA ORACLE) — Wed, 07 Jul 2010 17:40:00 +0000

Gestion d'une configuration Data Guard
Les bases de données principale et de secours et leurs diverses interactions peuvent être gérées
par l'intermédiaire de SQL*Plus. Data Guard offre également une infrastructure de gestion
répartie appelée Data Guard Broker, qui automatise et centralise la création, la maintenance et la
surveillance d'une configuration Data Guard. Les administrateurs peuvent interagir avec le
Broker via Enterprise Manager Grid Control ou l'interface de ligne de commande de Broker
(DGMGRL).
Enterprise Manager Grid Control comporte des assistants qui simplifient davantage encore la
création d'une configuration Data Guard. Les mesures clés de Data Guard telles que le retard
d'application, le retard de transport, le débit de journalisation et l'état de configuration, sont
inclus dans une nouvelle Console Haute Disponibilité (HA) consolidée (voir la Figure 4).
Enterprise Manager permet d'analyser la tendance historique sur les mesures de performances
Data Guard qu'il surveille ; par exemple, l'évolution des mesures de performances dans les
dernières 24 heures ou depuis 5 jours, etc. En outre, par l'intermédiaire d'Enterprise Manager, il
est possible de configurer des alarmes de notification de sorte que les administrateurs soient
informés si la mesure dépasse la valeur seuil configurée.

Data Guard

noreply@blogger.com (DBA ORACLE) — Wed, 07 Jul 2010 17:36:00 +0000

Maintenance planifiée
Vous pouvez utiliser une base de données de secours Data Guard afin de réduire les temps
d'arrêt et les risques pour de nombreux types de maintenances planifiées. L'approche générale
consiste à implémenter les modifications dans la base de secours, à réaliser des tests, puis à
procéder à la permutation. Toute maintenance n'impliquant pas de différences dans les versions
d'Oracle ni de modifications de la structure logique de la base de données peut faire appel à Redo
Apply. La mise à jour vers de nouvelles versions ou de nouveaux jeux de patches d'Oracle
Database ou la modification de la structure logique d'une base de données peuvent être réalisées
de façon non simultanée par le biais de SQL Apply, soit à l'aide d'une base de données de secours
logique, soit à l'aide d'une base de données de secours physique transformée en base de secours
logique de façon transitoire.
Le seul temps d'arrêt requis pour ce type de maintenance est celui nécessaire pour effectuer une
permutation (SWITCHOVER). Les permutations effectuées par le biais de Redo Apply peuvent
s'achever en moins de 60 secondes. Pour plus d'informations, consultez le document concernant
les meilleures pratiques MAA, Data Guard Switchover and Failover Best Practices (Meilleures
pratiques concernant la permutation et le basculement). Les permutations effectuées via SQL
Apply sont encore plus rapides étant donné qu'une base de secours logique est déjà ouverte en
lecture-écriture. SQL Apply est doté d'un paramètre « GUARD » qui empêche tout changement
des données répliquées à partir de la base principale pendant que le rôle de secours lui a été
affecté. Une permutation SQL Apply affecte officiellement le rôle de base principale à la base de
secours en modifiant simplement le paramètre GUARD. Bien que les durées puissent varier d'un
environnement à un autre, le basculement de base de données par l'intermédiaire de SQL Apply
peut s'effectuer en moins de 10 secondes. Pour plus d'informations, consultez le document
Oracle Japan GRID Center Performance Validation: Data Guard SQL Apply on IBM Power
Systems (Validation des performances d'Oracle Japan GRID Center : mode SQL Apply d'Oracle
Data Guard sur IBM Power Systems).
Les sections ci-après décrivent de façon détaillée les divers types de maintenances planifiées
pouvant être effectuées par le biais d'une base de données de secours Data Guard.

Validation de données Oracle

noreply@blogger.com (DBA ORACLE) — Wed, 07 Jul 2010 17:36:00 +0000

Validation de données Oracle
L'un des avantages importants de Data Guard est la possibilité d'utiliser des processus Oracle
pour valider les données de journalisation avant leur application à la base de secours. Data Guard
est une architecture de type « couplage lache » (loosely coupled) dans laquelle les bases de
données de secours restent synchronisées par l'application de blocs de journalisation ; elle n'est
pas impactée par d'éventuelles corruptions de fichiers de données pouvant se produire au niveau
de la base de données Primaire. Les données de journalisation sont également transmises
directement depuis la mémoire (SGA - System Global Area) et ne sont pas impactées par une
quelconque corruption d'E/S sur les fichiers de journalisation de la base Primaire.

Résolution automatique des décalages

noreply@blogger.com (DBA ORACLE) — Wed, 07 Jul 2010 17:36:00 +0000

Résolution automatique des décalages
Lorsque les bases de données Primaire et de secours ne sont plus connectées entre elles
(défaillances du réseau ou du serveur de secours), et selon le mode de protection utilisé, la base
Primaire va continuer à traiter les transactions et à accumuler une série de données de
journalisation qui ne peuvent pas être transférées vers la base de secours tant qu'une nouvelle
connexion réseau n'est pas établie. Dans cet état, Data Guard contrôle continuellement le statut
de la base de secours, détecte le rétablissement de la connexion et resynchronise
automatiquement la base de secours avec la base principale (quatrième étape de la Figure 3).
Aucune action humaine n'est requise tant que les fichiers de journalisation archivés nécessaires à
la resynchronisation de la base de secours sont disponibles sur disque au niveau de la base
principale. En cas de panne prolongée rendant difficile la conservation des fichiers de
journalisation archivés nécessaires, une base de secours physique peut être resynchronisée via une
sauvegarde incrémentale rapide RMAN de la base principale.

Résolution automatique des décalages

noreply@blogger.com (DBA ORACLE) — Wed, 07 Jul 2010 17:36:00 +0000

SQL Apply - Base de secours logique

noreply@blogger.com (DBA ORACLE) — Wed, 07 Jul 2010 17:32:00 +0000

SQL Apply - Base de secours logique
Une base de données de secours logique contient les mêmes informations logiques que la base
Primaire, bien que la structure et l'organisation physiques des données puissent être différentes.
SQL Apply permet de conserver la synchronisation d'une base de secours logique en
transformant les données de journalisation reçues de la base principale en instructions SQL, puis
en exécutant ces dernières sur une base de secours ouverte en lecture-écriture. SQL Apply
comporte quelques restrictions relatives aux types de données, de tables et d'opérations LDD et
LMD (voir la documentation sur les types de données et les attributs de stockage non pris en
charge).
Vous pouvez utiliser SQL Apply si vous remplissez les conditions requises et dans les cas
suivants :
• Vous souhaitez exécuter des applications de création d'états nécessitant un accès en
lecture-écriture dans la base de secours. Notez que vous ne pouvez pas modifier les
données gérées par SQL Apply.
• Vous souhaitez ajouter à votre base de données de secours des tables, des schémas,

SQL Apply - Base de secours logique

noreply@blogger.com (DBA ORACLE) — Wed, 07 Jul 2010 17:32:00 +0000

SQL Apply - Base de secours logique

noreply@blogger.com (DBA ORACLE) — Wed, 07 Jul 2010 17:32:00 +0000

Redo Apply et Active Data Guard

noreply@blogger.com (DBA ORACLE) — Wed, 07 Jul 2010 17:32:00 +0000

Redo Apply et Active Data Guard
L'option Active Data Guard inclut des fonctionnalités qui étendent les capacités de Redo Apply
et des bases de données de Standby physiques. Ces fonctionnalités sont les suivantes :
• Real-time Query permet un accès en lecture seule à une ou plusieurs bases de données
de secours physiques pour, notamment, les requêtes, le tri, la création d'états ou l'accès
Web, pendant que Redo Apply applique de façon continue les modifications reçues de la
base de données de production. Dans les cas où la charge de travail en lecture seule peut
être isolée des transactions en lecture-écriture, Active Data Guard peut véritablement
doubler la capacité de production en utilisant une base de données de secours physique
existante, jusque-là en état de veille dans le cadre de son rôle de secours. (Vous pouvez
ajouter des bases de secours actives supplémentaires à la configuration pour augmenter
la capacité de traitements en lecture seule sans impact sur les transactions en lectureécriture).
L'option Active Data Guard offre des performances exceptionnelles ; elle peut
être utilisée pour des applications à haut débit, pour lesquelles toute autre méthode de
réplication ne peut faire face au volume de transactions généré par la base de données
source.
• Vous pouvez implémenter les contrats de niveau de service Active Data Guard à l'aide
du paramètre de session STANDBY_MAX_DATA_DELAY. La valeur de ce paramètre
spécifie une limite relative au délai (en secondes) pouvant s'écouler entre la validation
des modifications sur la base principale et leur disponibilité via des requêtes effectuées
sur une base de données de secours active (nouveauté de Data Guard 11g Release 2). La
base de secours active renvoie un code d'erreur ORA-3172 si le délai est dépassé. Les
applications peuvent répondre à cette erreur de la même façon que pour une
déconnexion et rediriger l'interrogation vers une autre base de secours active ou vers la
base principale pour se conformer au contrat de niveau de service requis

Services d'application Data Guard

noreply@blogger.com (DBA ORACLE) — Wed, 07 Jul 2010 17:32:00 +0000

Services d'application Data Guard
Les services d'application (Apply Services) lisent les données de journalisation à partir d'un fichier
de journalisation de secours, les valident, puis les appliquent à la base de secours (deuxième étape
de la Figure 3) par le biais du mode Redo Apply (base de secours physique) ou SQL Apply (base
de secours logique). Notez que les services de transport et d'application sont totalement
indépendants. L’état ou les performances de l'application de la journalisation dur la base de
secours n'ont aucune incidence sur le transport des informations de journalisation ni sur les
performances de la base de données principale. Cet isolement est crucial. Le transport des
informations de journalisation est le principal facteur déterminant du point de récupération
maximum, facteur de risque potentiel de pertes de données. Tout impact négatif sur le transport
augmente le risque de pertes de données. Le transport des informations de journalisation dans
des configurations synchrones est également crucial dans la détermination de l'impact sur le
temps de réponse et le débit de la base de données Primaire. Tout impact négatif sur le transport
dans une configuration synchrone peut réduire le débit et augmenter le temps de réponse de la
base de données Primaire. L'isolement des opérations de transport et d'application a pour but
d'optimiser les performances de la base, son temps de réponse et la protection des données.

Services de transport Data Guard

noreply@blogger.com (DBA ORACLE) — Wed, 07 Jul 2010 17:32:00 +0000

Services de transport Data Guard
Au fur et à mesure que les utilisateurs valident des transactions dans la base de données
principale (COMMIT), Oracle génère des enregistrements de journalisation et les écrit dans un
fichier journal en ligne local. Les services de transport Data Guard transmettent les données de
journalisation à une base de données de secours de façon synchrone ou asynchrone, où elles sont
écrites dans un fichier de journalisation de secours (première étape de la Figure 3). Les données
de journalisation peuvent être transmises au format compressé pour réduire les besoins en
matière de bande passante à l'aide de l'option Oracle Advanced Compression.
Transport des informations de journalisation synchrone (SYNC) : la base de données
Primaire attend de la base de données de secours la confirmation que les données de
journalisation ont été sauvegardées sur disque avant d'indiquer le succès de la validation à
l'application, empêchant ainsi toute perte de données. Les performances de la base de données
Primaire sont affectées par le délai requis pour l'achèvement des opérations d'E/S du fichier de
journalisation de la base Standby et le temps de round-trip du réseau.
Data Guard 11g Release 2 est conçue pour limiter l'impact du transport synchrone sur les
performances de la base Primaire . Les données de journalisation sont désormais transmises à la
base de secours distante simultanément avec l'E/S du fichier journal en ligne local sur la base de
données Primaire, supprimant ainsi toute répercussion de l'E/S de secours sur le temps de
round-trip total. Cela permet un éloignement géographique plus important entre les bases de
données Primaire et de secours dans le cadre d'une configuration synchrone sans perte de
données. Sur les réseaux à faible temps d'attente, l'impact de la réplication SYNC sur les
performances de la base de données principale peut être pratiquement nul ; dans ce cas, il peut
être intéressant d'associer une base de secours ASYNC distante à une base de secours SYNC
locale pour une protection Haute Disponibilité, garantissant l'absence de perte de données,
contre les défaillances au niveau des composants et des bases de données (défaillance du SAN,
par exemple).

Fonctionnement de Data Guard – Détails techniques

noreply@blogger.com (DBA ORACLE) — Wed, 07 Jul 2010 17:32:00 +0000

Fonctionnement de Data Guard – Détails techniques
Une configuration Data Guard comporte une base de données de production, appelée base
Primaire, et jusqu'à 30 bases de données de secours. Les bases de données Primaire et de secours
se connectent en TCP/IP via Oracle Net Services. L'emplacement des bases de données importe
peu, tant qu'elles peuvent communiquer entre elles. Une base de données de secours est
initialement créée à partir d'une copie de sauvegarde de la base Principale. Data Guard
synchronise automatiquement la base de données Primaire et toutes ses bases de secours en
transmettant les informations de journalisation de la base de données principale (les données
utilisées par Oracle pour récupérer des transactions) et en les appliquant à la base de données de
secours.

Oracle Data Guard 11g

noreply@blogger.com (DBA ORACLE) — Wed, 07 Jul 2010 17:32:00 +0000

Oracle Data Guard 11g - Présentation
Oracle Data Guard procure les infrastructures logicielles d’administration, de surveillance et
d'automatisation nécessaires à la création et à la gestion d'une ou plusieurs bases de données de
secours destinées à protéger les données Oracle contre les défaillances, les sinistres, les erreurs et
la corruption des données. Il existe deux types de bases de données de secours. Une base de
données de secours physique fait appel au mode Redo Apply pour maintenir une réplique exacte,
bloc pour bloc, de la base de données Primaire. Une base de données de secours logique fait
appel au mode SQL Apply et contient les mêmes informations logiques que la base de données
principale, bien que l'organisation et la structure physiques des données puissent être différentes

Oracle Migration consulting support

noreply@blogger.com (DBA ORACLE) — Mon, 05 Jul 2010 20:25:00 +0000

For complete Oracle migration support, just call and get expert advice today. We offer complete migration support for all databases.

We offer migration support consulting in these areas:

*

Sybase Oracle Database Migration Support
*

SQL Server to Oracle Database Migration Support
*

Informix to Oracle Database Migration Support
*

Oracle Migration from Solaris to Linux
*

Migration to Oracle cost based SQL optimization
*

Oracle 10g Migration for Oracle10g

We are the Oracle certified professionals ro call for any Oracle migration issue.

Remote DBA BC Oracle Remote DBA Support

noreply@blogger.com (DBA ORACLE) — Mon, 05 Jul 2010 20:24:00 +0000

BC Remote DBA Oracle support is the oldest Remote DBA Oracle support provider, serving clients throughout the world.

Our Remote DBA staff consists of Oracle-certified experts and authors, professional Remote DBAs with a commitment to excellence in service.

BC Remote DBA specializes in Remote DBA service for mission critical Oracle databases that require high levels of performance, reliability and security.

BC Remote DBA service uses proprietary remote Oracle monitoring and Oracle support techniques that are not available anywhere else to perform proactive tuning for your Oracle database.

BC Remote DBA Service carefully protects your data privacy and uses only trustworthy Oracle experts. Read our Remote DBA security policy. We can also provide Oracle remote consulting by experts with an active US security clearance.

Our copyrighted Remote DBA Oracle support detection techniques have made us successful in providing remote Oracle support for some of the world's most sophisticated Oracle databases.

BC Remote DBA Oracle support services are an attractive outsourcing option for many reasons, and you are protected with by USA privacy laws and our Oracle certified remote support staff. These are just a few reasons why BC remote Oracle Remote DBA support is #1 for remote Oracle in the USA . Here are some tips on how to choose Oracle Remote DBA packages.
BC Remote DBA Service has encapsulated decades of Oracle monitoring experience into a single package, the Remote Preemptive Monitor for Oracle™, a proactive package that detects impending problems before they cripple your database. You lease RPM for Oracle by the month for extra insurance against database failures and guaranteed access to Oracle experts for problem resolution.

Custom Remote DBA support

BC Oracle Remote DBA support provides remote Oracle support and Oracle Remote DBA consulting that is customized according to your database needs. Many companies are improving the quality of their Oracle support while saving tens of thousands of dollars yearly by replacing an expensive full-time Remote DBA with Remote DBA support services.

BC Remote DBA Oracle support staff has the highest standard in the Remote Oracle support industry, and all remote Oracle Remote DBA consultants are Oracle Certified with extensive real-world experience.

Why choose BC Remote DBA for remote Oracle support?

BC is the oldest and most respected Oracle remote support firm with a proven track record. We employ some of the world's top remote Oracle experts who have published more than dozens of Oracle books on remote Oracle and Remote DBA support technology.

BC Remote DBA support only uses Oracle certified Remote DBA consultants in our response centers who constantly monitor your databases, fixing problems before they effect your Oracle performance. Your staff develops a personal relationship with your Remote DBA, and once you are assigned a primary and secondary Remote DBA, you will be able to contact them at any time, day or night.

BC Oracle Remote DBA is managed by some of the world's leading Oracle consultants and authors, noted experts in remote Oracle Remote DBA and database monitoring technologies.

BC ensures that all Oracle support clients receive the best possible Oracle development, Oracle training & remote database support.

Because of our extensive experience with automating Oracle support database administration tasks, we are able to offer professional remote Oracle Remote DBA support at affordable prices.

*

MySQL Remote DBA Support Plans & Prices
*

SQL Server Remote DBA Support Plans & Prices
*

Oracle 9i de-support coming in July 2007
*

BC Oracle TechBlast at Sea!

Oracle Training Experts

noreply@blogger.com (DBA ORACLE) — Mon, 05 Jul 2010 20:23:00 +0000

BC Oracle training wrote the book on custom Oracle training. Our instructors have authored more than 50 bestselling Oracle books and have dedicated their professional careers to training Oracle professionals.

Don't hire a slide-flipper. All BC instructors have extensive work experience and most are noted Oracle experts and published Oracle authors. BC enhances your Oracle training class with instructors who have been there, real, working Oracle professionals.
Oracle DBA Training Oracle Developer Training
Custom Oracle Training Classes Oracle eBusiness Suite Training
Oracle 11g Training

Download Oracle Training Catalog

We Guarantee Your Oracle Training Success

With personal hands-on training, and optional follow-up mentoring, you can guarantee that your training investment provides the maximum benefit. We develop a personal relationship with your students and ensure that we maximize their learning and we offer supplemental mentoring by your instructor.

All Oracle Training instructors are seasoned Oracle professionals with many years of on-the-job experience and all BC Oracle instructors are Oracle Certified Professionals and are specially trained to offer a hands-on, pragmatic learning experience.

Oracle Performance Tuning Consulting

noreply@blogger.com (DBA ORACLE) — Mon, 05 Jul 2010 20:22:00 +0000

BC consultants are masters of Oracle performance tuning offering expert Oracle performance tuning support. BC experts wrote the book on Oracle performance tuning and know exactly how to quickly and reliably optimize any Oracle database, large or small. BC has developed proprietary Oracle performance tuning tools to ensure optimal Oracle performance and to identify performance problems before they cripple your database.

Use a Real Tuning Expert

BC is the USA's oldest and most respected group of Oracle Performance tuning experts,specilizing in Oracle Performance tuning for large, high volume mission-critical databases. With the highest selection standards in the Oracle industry, BC's Oracle Performance Tuning experts are the best of the best, Oracle certified experts and respected authors who do Oracle Performance tuning for a living:

Oracle RAC performance tuning
Oracle SQL Tuning
Oracle Health Checks
Oracle server tuning

Oracle AIX I/O Tuning

noreply@blogger.com (DBA ORACLE) — Thu, 01 Jul 2010 21:40:00 +0000

Oracle AIX I/O Tuning

Asynchronous I/O allows a program to initiate I/O and continue execution of useful work, while other I/O operations are carried out in parallel by the operating system. Because Oracle applications often require multiple server and user processes at the same time, they take advantage of asynchronous I/O to overlap program execution with I/O operations.

Asynchronous I/O is used with Oracle on the AIX operating system to improve system performance.
In AIX V5.2 and newer versions, two asynchronous I/O subsystems are supported, the original asynchronous I/O (called Legacy asynchronous I/O), and the new POSIX asynchronous I/O.

The two types of asynchronous I/O differ in the way the asynchronous I/O subsystem API is defined. Their performance characteristics are the same. All Oracle releases up to and including the current release, Oracle Database 10g, use Legacy asynchronous I/O.

AIX Oracle large page support

noreply@blogger.com (DBA ORACLE) — Thu, 01 Jul 2010 21:39:00 +0000

AIX Oracle large page support

Give the Oracle user ID the CAP_BYPASS_RAC_VMM and CAP_PROPAGATE capabilities by following these steps:
1. First check the current capabilities: #lsuser –a capabilities oracle
Note: only the root user can display the capabilities attribute.
2. Add the CAP_BYPASS_RAC_VMM and CAP_PROPAGATE capabilities to the list of capabilities already assigned to this user ID, if any: #chuser capabilities=CAP_BYPASS_RAC_VMM,CAP_PROPAGAE oracle
3. Configure the AIX large page pool by calculating the number of large pages required for the SGA: num_of_large_pages = INT((total_SGA_size-1)/16MB)+1
4. Configure the number and size of large pages: #vmo -p -o lgpg_regions=num_of_large_pages -o lgpg_size=16777216

Oracle AIX memory pinning

noreply@blogger.com (DBA ORACLE) — Thu, 01 Jul 2010 21:39:00 +0000

Oracle AIX memory pinning

The AIX operating system allows shared memory to be allocated in pinned memory for improved performance. Pinned memory is always present in real memory; it is not paged in and out. The primary advantage of using pinned memory for the Oracle System Global Area (SGA) is that I/O from pinned memory is optimized for improved path length.

This is possible because the asynchronous I/O routines do not need to pin the SGA memory each time it is used for an I/O operation. Because of this performance improvement, it is best to use pinned memory to allocate the Oracle SGA.
When the Oracle initialization parameter LOCK_SGA is set to TRUE, Oracle will allocate shared memory for the SGA using the AIX pinned memory. (Note: shmget() is called with the SHM_PIN flag set.) In addition to setting the Oracle LOCK_SGA parameter to TRUE, the AIX operating system must be configured to allow pinned memory to be used for shared memory.

Oracle AIX Process Memory tuning

noreply@blogger.com (DBA ORACLE) — Thu, 01 Jul 2010 21:38:00 +0000

Oracle AIX Process Memory tuning

The AIX operating system provides a robust environment for running processes with a wide variety of execution characteristics. By taking advantage of the many variables and features to tune the process environment specifically for the Oracle application, memory usage of each Oracle process is reduced.

The AIXTHREAD_SCOPE environment variable can be used for control if a process runs with process-wide contention scope (the default) or with system-wide contention scope. When using system-wide contention scope, there is a one-to-one mapping between the user thread and a kernel thread. On UNIX® systems, Oracle applications are primarily multiprocess and single-threaded.

One of the mechanisms that enables this multiprocess system to operate effectively is the AIX post/wait mechanism: thread_post(), thread_post_many(), and thread_wait(). It operates most effectively with the Oracle application when using system-wide contention scope (AIXTHREAD_SCOPE=S).

As of AIX V5.2, system-wide contention scope will also significantly reduce the memory required for each Oracle process. For these reasons, always export AIXTHREAD_SCOPE=S before starting all Oracle processes. In Oracle Database 10g a newer, system-wide contention scope is set internally when the instance and user processes are started.