Oracle Concurrent Manager

• Types d'Oracle Concurrent Manager
  • Gestionnaire simultané interne (ICM)
  • Gestionnaires de services (FNDSM)
  • Moniteurs internes (FNDIMON)
  • Gestionnaires simultanés Oracle (FNDLIBR,INVLIBR)
• Description des tables oracle importantes d'Oracle Concurrent Manager
• Tableaux du gestionnaire simultané
• Description de l'état de la phase de demande simultanée
• comment démarrer le gestionnaire simultané dans les applications oracle r12
• comment arrêter le gestionnaire simultané dans les applications oracle r12
• comment vérifier l'état du gestionnaire simultané dans les applications oracle r12
• Emplacement du fichier journal du gestionnaire simultané dans R12
• Dépannage du gestionnaire simultané
• SCRIPTS DE SERVEUR DE TRAITEMENT CONCURRENT
• Comment effectuer un réglage simultané du gestionnaire
• Cours recommandés

Types d'Oracle Concurrent Manager

Gestionnaire simultané interne (ICM)

L'Internal Concurrent Manager (ICM) peut être considéré comme le « cerveau » du traitement simultané. Il est responsable des fonctionnalités suivantes :

-Démarre tous les autres processus comme le gestionnaire de résolution des conflits, le gestionnaire standard
-Exécute les « demandes de contrôle » soumises par l'administrateur.
-Active/Désactive/Abandonne le gestionnaire simultané
-Termine la demande simultanée
-Surveille les processus, en redémarrant ceux qui ont échoué.
-Définit le nombre cible de processus pour chaque service en fonction du quart de travail actuel.

Démarrer l'ICM

-script adcmctl.sh
-TNS Apps Listener doit être démarré avant de lancer ICM

Arrêter l'ICM

-L'arrêt de l'ICM arrêtera tous les autres services comme le gestionnaire de résolution des conflits, le gestionnaire standard
– L'arrêt normal signale aux processus de se terminer après avoir terminé leurs tâches en cours.
– L'abandon mettra fin aux processus de service.
– ICM ne se fermera pas tant que tous les autres processus ne seront pas terminés.
-Utilisez adcmctl.sh pour arrêter ICM.

Gestionnaires de services (FNDSM)

Les gestionnaires de service sont générés sur les nœuds de niveau intermédiaire d'un système compatible GSM afin d'agir en tant qu'agent de l'ICM. Lorsque l'ICM constate qu'il a besoin d'un gestionnaire de service pour exécuter une fonction, telle que le démarrage d'un processus de gestionnaire simultané, sur un nœud de niveau intermédiaire, il effectue des appels de contrôle de procédure à distance vers l'écouteur Apps sur ce nœud pour démarrer le gestionnaire de service. Une fois que le gestionnaire de service a été démarré et initialisé, l'ICM communique directement avec le gestionnaire de service via un appel procédural à distance (RPC), en lui donnant des informations pour gérer les services sur ce nœud.

-Le gestionnaire de service est généré à partir de l'écouteur APPS TNS
– L'écouteur APPS TNS doit être démarré sur chaque nœud de niveau intermédiaire du système et démarré par l'utilisateur qui démarre ICM (par exemple, applmgr)
- TNS Listener génère le gestionnaire de service pour qu'il s'exécute en tant qu'agent d'ICM pour le nœud local
- Le gestionnaire de service est démarré par ICM à la demande en cas de besoin. Si aucune action de gestion n'est nécessaire sur un nœud, un gestionnaire de service ne sera pas démarré par ICM tant que cela n'est pas nécessaire. Lorsque ICM quitte ses gestionnaires de service, quittez également.
-L'environnement Service Manager est défini par APPSORA.env comme défini dans listener.ora
-Les fichiers listener.ora et tnsnames.ora doivent être correctement configurés pour l'écouteur pour pouvoir générer le gestionnaire de service et pour que l'ICM puisse vérifier l'état du gestionnaire de service.

Moniteurs internes (FNDIMON)

Les moniteurs internes sont utilisés spécifiquement dans le traitement simultané parallèle pour permettre le basculement du gestionnaire simultané interne vers d'autres nœuds de niveau intermédiaire disponibles.

-Placez un moniteur interne sur n'importe quel nœud où l'ICM peut démarrer en cas de panne.
-Les moniteurs internes sont amorcés sur chaque nœud enregistré par défaut.
-Si l'ICM tombe en panne, le moniteur interne essayez de démarrer un nouvel ICM sur le nœud local.
-Si plusieurs ICM sont démarrés, seul le premier restera actif. Les autres sortiront gracieusement.

Gestionnaires simultanés Oracle(FNDLIBR,INVLIBR)

Les gestionnaires simultanés fournissent un traitement de travail asynchrone en surveillant la table FND_CONCURRENT_REQUESTS sur un cycle continu. Le travail d'un gestionnaire simultané consiste à exécuter des demandes simultanées qui sont en attente/phase normale/statut et qu'il est qualifié pour exécuter selon ses règles de spécialisation.

Processus de gestionnaire simultanés
– Agir de manière indépendante
– Sélectionner uniquement les demandes qui :(a) correspondent aux règles de spécialisation du gestionnaire, (b) sont en attente/normales, (c) ont une heure de début demandée

Description des tables oracle importantes d'Oracle Concurrent Manager

FND_CONCURRENT_QUEUES
TARGET_NODE
-Utilisé pour indiquer où les processus supplémentaires doivent être démarrés
-Utilisé par les responsables pour déterminer s'ils doivent s'arrêter eux-mêmes pour la migration
-Les responsables comparent la valeur du paramètre transmis au démarrage à cette valeur
-Utilisée par l'interface utilisateur pour indiquer où les processus existent (pas tout à fait précis dans le cas de la migration)
-Attribué par ICM en fonction des paramètres primaires et secondaires

NODE_NAME
-Indique le nœud principal pour PCP – chargement dirigé
-L'endroit où les processus doivent être démarrés à moins que le nœud ne soit pas en ligne ou qu'il ait été déterminé qu'il n'est pas disponible
-Si aucun nœud n'est spécifié, ICM attribuera une cible nœud par défaut sur NODE_NAME2
-Indique le nœud secondaire pour PCP – Basculement de charge dirigée
-Affecté uniquement en tant que TARGET_NODE si le nœud principal n'est pas disponible

FND_CONCURRENT_PROCESSES
NODE_NAME
-Indique où le processus du gestionnaire est en cours d'exécution
-Indique également où se trouvent les fichiers du gestionnaire
-Renseigné à l'aide de la valeur de uname() (nom de la machine physique)
-Utilisé par ICM lors de la fin du processus
-Utilisé lors de l'affichage du fichier journal dans l'interface utilisateur (UI)
-Utilisé par le programme Purge pour supprimer le fichier journal du processus
-Peut être utilisé pour les calculs de statistiques de charge de travail
/>-Sera probablement utilisé par les RPM pour tenter de trouver un OPP local
-Semblable utilisé dans 11i.X pour localiser le serveur de rapports

FND_CONCURRENT_REQUESTS
LOGFILE_NODE_NAME, OUTFILE_NODE_NAME
-Indique où les fichiers existent
-Utilisé dans l'interface utilisateur (UI) pour l'affichage des fichiers
-Utilisé par le programme de purge pour supprimer des fichiers
-Valeur renseignée par processus mgr, basé sur son propre nœud

FND_NODES

NODE_NAME
-Indique le nom du nœud où se trouve le fichier DBC.
-Le script Adgendbc.sh crée le fichier DBC.

SERVER_ID
-Sera utilisé pour authentifier les connexions à partir du nœud.
-Mise à jour par adgendbc.sh qui appelle l'API AdminAppServer.

Tableaux du gestionnaire simultané

FND_NODES : contient toutes les informations au niveau des nœuds

FND_CONCURRENT_PROCESSES : Contient toutes les informations sur le processus du gestionnaire de simultanéité
FND_CONCURRENT_REQUESTS : Contient un historique complet de toutes les requêtes simultanées (à la fois l'historique passé et celles dont l'exécution est prévue dans le futur).

FND_CONCURRENT_QUEUES :Contient les informations pour tous les gestionnaires simultanés créés dans le système
FND_CONCURRENT_PROGRAMS :Contient les informations pour tous les programmes simultanés disponibles dans le système
FND_EXECUTABLES
FND_CP_SERVICES
FND_CONCURRENT_QUEUE_SIZE
FND_CONCURRENT_QUEUE_CONTENT
FND_CONCURRENT_PROGRAM_SERIAL
FND_CONCURRENT_TIME_PERIODS
FND_CONCURRENT_PROCESSORS

FNDSVCRG
L'exécutable FNDSVCRG est déclenché à partir des scripts de contrôle avant et après qu'un script démarre ou arrête le service. FNDSVCRG se connectera à la base de données pour vérifier la configuration du service GSM amorcé. Si le service en question n'est pas habilité à être géré sous GSM, l'exécutable FNDSVCRG ne fera rien et sortira. Le script continuerait alors à effectuer ses actions de démarrage/arrêt normales. Si le service est activé pour la gestion GSM, l'exécutable FNDSVCRG mettra à jour les informations relatives au service dans la base de données, y compris le contexte de l'environnement, l'emplacement actuel du fichier journal du service et l'état actuel du service

Description de l'état de la phase de demande simultanée

EN ATTENTE/Normal -La demande attend le prochain gestionnaire disponible.
EN ATTENTE/Veille -Le programme pour exécuter la demande est incompatible avec un autre programme en cours d'exécution.
EN ATTENTE/Planifié -La demande est programmée pour commencer à une heure ou une date future.
EN ATTENTE/EN ATTENTE -Une requête enfant attend sa requête parent pour la marquer comme prête à s'exécuter. Par exemple, une requête dans un ensemble de requêtes qui s'exécute de manière séquentielle doit attendre qu'une requête précédente se termine.
RUNNING/Normal -La requête s'exécute normalement.
EN COURS D'EXÉCUTION/Pause -La requête parent s'interrompt pour que toutes ses requêtes enfants finissent de s'exécuter. Par exemple, un ensemble de requêtes s'interrompt pour que toutes les requêtes de l'ensemble se terminent.
EXÉCUTION/Reprise - Toutes les requêtes soumises par la même requête parent ont été exécutées. La requête parent reprend son exécution.
EXÉCUTION/Arrêt -La demande est terminée en cliquant sur le bouton Annuler la demande dans la fenêtre Demandes.
COMPLETED/Normal -Demande terminée avec succès.
COMPLETED/Erreur - La demande n'a pas abouti.
COMPLETED/Avertissement -Demande terminée avec des avertissements. Par exemple, une demande est générée avec succès mais ne s'imprime pas.
COMPLETED/Cancelled -La demande en attente ou inactive est annulée en cliquant sur le bouton Annuler la demande dans la fenêtre Demandes.
COMPLETED/Terminé -La demande est terminée en cliquant sur le bouton Annuler la demande dans la fenêtre Demandes.
INACTIVE/Désactivé -Le programme pour exécuter la demande n'est pas activé. Contactez votre administrateur système.
INACTIF/En attente- La demande en attente est mise en attente en cliquant sur le bouton Suspendre la demande dans la fenêtre Demandes.
INACTIF/Aucun gestionnaire -Aucun gestionnaire n'est défini pour exécuter la requête. Vérifiez auprès de votre administrateur système. Un statut Aucun gestionnaire est également donné lorsque tous les gestionnaires sont verrouillés par des demandes d'exécution seules.

comment démarrer le gestionnaire simultané dans les applications oracle r12

Démarrer le gestionnaire simultané dans R12
Connectez-vous à l'utilisateur du niveau d'application, généralement son applmgr

cd $ADMIN_SCRIPTS_HOME
./adcmctl.sh start apps/<apps-pass>

comment arrêter le gestionnaire simultané dans les applications oracle r12

Arrêter le gestionnaire simultané dans R12
Connectez-vous à l'utilisateur du niveau d'application, généralement son applmgr

cd $ADMIN_SCRIPTS_HOME
./adcmctl.sh stop apps/<apps-pass>

comment vérifier l'état du gestionnaire simultané dans les applications oracle r12

Pour vérifier le statut du gestionnaire simultané
Connectez-vous à l'utilisateur du niveau d'application, généralement son applmgr

cd $ADMIN_SRCIPTS_HOME
./adcmctl.sh status apps/<apps-pass>

Emplacement du fichier journal du gestionnaire simultané dans R12

Concurrent Manager, ICM et la demande simultanée génèrent tous les fichiers journaux

A) Fichier journal des demandes simultanées - documente l'exécution d'une demande particulière ( l.req )
B) Fichier journal du gestionnaire - documente les performances d'un processus de gestionnaire simultané. ( W.mgr )
C) Fichier journal interne du gestionnaire – documente les performances de l'ICM.(std.mgr). Ce fichier journal affiche les paramètres utilisés avec la commande 'adcmctl'.

si $APPLCSF est défini

Les fichiers journaux se trouvent dans le dossier $APPLCSF/$APPLLOG.
Les fichiers journaux peuvent également être consultés depuis les applications à partir du formulaire Afficher les demandes simultanées

R12.2  APPLCSF =$NE_BASE/inst//logs/appl/conc/log

R12.1 APPLCSF=$INST_TOP//logs/appl/conc/log

Si $APPLCSF n'est pas défini

Les fichiers journaux se trouvent dans le dossier $PRODUCT_TOP/$APPLLOG.

De même pour les fichiers de sortie,

si $APPLCSF est défini

R12.2 APPLCSF=$NE_BASE/inst//logs/appl/conc/

R12.1 APPLCSF=$INST_TOP//logs/appl/conc/

Dépannage du gestionnaire simultané

Comment vérifiez-vous l'état des gestionnaires simultanés Oracle à partir du système d'exploitation
–Commande Linux :

$ ps -ef | grep LIB

-Notez que le gestionnaire simultané interne peut être repéré dans cette liste car sa commande est "FNDLIBR FND CPMGR…" alors que les autres ressemblent davantage à "FNDLIBR FND Concurrent_Processor…"
-L'ID utilisateur Unix affiché dans la première colonne de cette la liste est cruciale :ces processus de gestion simultanée doivent appartenir au même ID utilisateur Unix qui possède le code Applications ($APPL_TOP et ses sous-répertoires) ; cet utilisateur est généralement appelé "applmgr"

Où vont tous les fichiers générés par les gestionnaires simultanés Oracle

-Le fichier journal ICM va dans le répertoire $FND_TOP/log et correspond généralement std.mgr.
-Les fichiers journaux des travailleurs vont dans $FND_TOP/log et correspondent à W.mgr
-Le les fichiers de déconnexion/déconnexion des demandes simultanées vont sous le répertoire supérieur du produit associé au produit exécutant la demande :par exemple, les fichiers de déconnexion/déconnexion pour les rapports AR vont sous $AR_TOP.
-Les fichiers journaux pour les demandes simultanées vont dans le répertoire $ Sous-répertoire APPLLOG sous le répertoire supérieur du produit approprié et faites correspondre l .req. Ce répertoire $APPLCSF sera utilisé à la place des différents répertoires principaux du produit pour écrire
tous les fichiers de déconnexion/déconnexion.

Les problèmes de gestion simultanée les plus courants sont dus à des problèmes de protection des fichiers au niveau Unix/linux.

-Démarrez-vous les gestionnaires simultanés en tant qu'applmgr ?
-Applmgr peut-il effectuer les opérations suivantes pour créer un fichier dans le
répertoire $FND_TOP/$APPLLOG ?
Répertoire $FND_TOP/$APPLOUT ?
/>Unix :$ touch $FND_TOP/$APPLLOG/a
-Si cela échoue, à qui appartient le répertoire ?
Unix :$ ls -ld $FND_TOP/$APPLLOG
-Ce répertoire est-il un lien symbolique ? Si oui, quelles sont les protections sur le répertoire vers lequel il pointe ?
-Vous manquez d'espace disque sur cette partition ? i-nodes ?
Unix :$ df -k
Unix (sur certains systèmes) pour vérifier les i-nodes :$ df -i
-APPLCSF est-il défini ?
-Si oui , est-ce que applmgr peut faire cela ?
Unix : $ touch $APPLCSF/$APPLLOG/a
-Vérifiez les répertoires $APPLOUT (généralement "out"), tout comme les répertoires de journaux.

Si un programme simultané PL/SQL ne peut pas écrire dans un fichier externe, vous recevrez un message d'erreur semblable à :

MSG-00102: Error Message :ORA-20100: File o0000071.tmp creation for FND_FILE failed.
You will find more information on the cause of the error in request log.
ORA-06512: at "APPS.FND_FILE", line 378
ORA-06512: at "APPS.FND_FILE", line 473
ORA-06512: at "APPS.AP_XYZ", line 192
REP-1419: 'beforereport': PL/SQL program aborted.

REMARQUE :Applications produit également des fichiers de sortie PL/SQL temporaires utilisés dans le traitement simultané. Ces fichiers sont écrits à un emplacement sur le nœud du serveur de base de données spécifié par le paramètre d'environnement APPLPTMP. Le répertoire APPLPTMP doit être le même répertoire que celui spécifié par le paramètre utl_file_dir dans votre fichier d'initialisation de base de données.
.
L'installation rapide définit à la fois APPLPTMP et le paramètre utl_file_dir sur le même répertoire par défaut. Comme les fichiers temporaires placés dans ce répertoire peuvent contenir des informations contextuelles, il doit s'agir d'un répertoire sécurisé sur le nœud du serveur de base de données avec un accès en lecture et en écriture pour le propriétaire du serveur de base de données. Dans un système à plusieurs nœuds, le répertoire défini par APPLPTMP n'a pas besoin d'exister sur les serveurs de niveau application. Lors d'une mise à niveau avec AutoUpgrade, vous devez fournir la valeur du paramètre utl_file_dir pour le paramètre d'environnement APPLPTMP.

Pour isoler où se situe le problème, vérifiez ce qui suit :

1) Assurez-vous que le nom du fichier est valide (le nom du fichier ne doit pas contenir de caractères tels que "^")

2) Assurez-vous que APPLPTMP est défini sur un répertoire valide et que l'utilisateur applmgr et l'utilisateur de la base de données disposent des autorisations de lecture et d'écriture sur ce répertoire (normalement, il peut être défini sur le même répertoire que APPLTMP)

3) Assurez-vous que le fichier ne se trouve pas dans le répertoire pointé par APPLPTMP

4) Assurez-vous que le répertoire pointé par APPLPTMP est la première entrée du utl_file_dir. Vérifiez également que toutes les entrées de utl_file_dir sont valides et que applmgr dispose des autorisations de lecture/écriture.

Si vous utilisez un fichier spfile, vérifiez la syntaxe appropriée pour définir utl_file_dir :

Ex.

ALTER SYSTEM SET UTL_FILE_DIR='directory1','directory2' scope=spfile;

5) Si vous rencontrez toujours des problèmes, vérifiez si vous pouvez écrire un fichier directement à l'aide de FND_FILE, qui est le package utilisé par l'application. Depuis SQLPLUS, connecté en tant qu'utilisateur des applications, exécutez :

SQL> exec FND_FILE.PUT_LINE(FND_FILE.LOG, 'THIS IS A TEST');

Cela devrait vider un fichier sur APPLPTMP.

Si ce test fonctionne, cela indiquerait que FND_FILE est OK et que le problème vient peut-être de l'application.

Vous voudrez peut-être ne laisser qu'une seule entrée sur utl_file_dir pour ce test.

6) Si vous rencontrez toujours des problèmes, vérifiez si vous pouvez écrire un fichier en utilisant UTL_FILE, qui est utilisé par FND_FILE.

Exécutez le PL/SQL ci-dessous, en passant à la première entrée sur utl_file_dir (vous pouvez ne laisser qu'une seule entrée sur utl_file_dir pour ce test).

set serveroutput on
DECLARE file_location VARCHAR2(256) := '';
file_name VARCHAR2(256) := 'utlfile1.lst';
file_text VARCHAR2(256) := 'THIS IS A TEST';
file_id UTL_FILE.file_type;
BEGIN
file_id := UTL_FILE.fopen(file_Location,file_name, 'W');
UTL_FILE.put_line(file_id, file_text);
UTL_FILE.fclose(file_id);
EXCEPTION
WHEN UTL_FILE.INVALID_PATH
THEN
dbms_output.put_line('Invalid path ' || SQLERRM);
WHEN OTHERS
THEN
dbms_output.put_line('Others '|| SQLCODE || ' ' || SQLERRM);
END;
/

Ce programme devrait vider un fichier dans le répertoire demandé. Si le test échoue, le problème vient probablement du côté de la base de données.

SCRIPTS DE SERVEUR DE TRAITEMENT CONCURRENT

afcmstat.sql Affiche tous les gestionnaires définis, leur capacité maximale, leurs pid et leur statut.
afimchk.sql Affiche l'état de la méthode ICM et PMON en vigueur, le fichier journal de l'ICM et détermine si le moniteur de gestion simultanée est en cours d'exécution.
afcmcreq.sql Affiche le gestionnaire simultané et le nom de son fichier journal qui a traité une demande.
afrqwait.sql Affiche les demandes en attente, en attente et planifiées.
afrqstat.sql Affiche le résumé de l'heure et de l'état d'exécution des requêtes simultanées depuis une date particulière.
afqpmrid.sql Affiche l'ID de processus du système d'exploitation du processus FNDLIBR en fonction d'un ID de demande simultanée. L'ID de processus peut ensuite être utilisé avec l'utilitaire ORADEBUG.
afimlock.sql Affiche l'ID de processus, le terminal et l'ID de processus susceptibles de provoquer des verrous que l'ICM et le CRM attendent d'obtenir. Vous devez exécuter ce script s'il y a de longs retards lors de la soumission des travaux, ou si vous pensez que l'ICM est dans une impasse avec un autre processus oracle.

Comment effectuer un réglage simultané du gestionnaire

Réglage du gestionnaire simultané interne (ICM)

Les performances d'ICM sont affectées par les trois paramètres Oracle importants, le cycle PMON, la taille de la file d'attente et le temps de veille.

Cycle PMON — Il s'agit du nombre de cycles de veille que l'ICM attend entre le moment où il vérifie les échecs des gestionnaires simultanés, qui est par défaut de 20. Vous devez modifier le cycle PMON à un nombre inférieur à 20 si vos gestionnaires simultanés ont des problèmes avec des problèmes anormaux. résiliations.

Taille de la file d'attente — La taille de la file d'attente est le nombre de cycles PMON que le missile aux performances améliorées attend entre la vérification des gestionnaires simultanés désactivés ou nouveaux. La valeur par défaut pour la taille de file d'attente de 1 cycle PMON doit être utilisée.

Temps de sommeil — Le paramètre de temps de sommeil indique les secondes que l'ICM devrait attendre entre vérifier les demandes qui attendent pour fonctionner. Le temps de veille par défaut est de 60, mais vous pouvez réduire ce nombre si vous voyez que vous avez beaucoup de demandes en attente (en attente/normal). Cependant, la réduction de ce nombre à une valeur très faible peut entraîner une utilisation excessive du processeur.

Ajustement de la taille du cache du gestionnaire simultané individuel

Les performances du gestionnaire simultané peuvent également être améliorées en augmentant la taille du cache du gestionnaire pour qu'elle corresponde au moins au double du nombre de processus cible. La taille du cache spécifie le nombre de requêtes qui seront mises en cache chaque fois que le gestionnaire de traitements simultanés lit la table FND_CONCURRENT_REQUESTS. L'augmentation de la taille du cache augmentera le débit des gestionnaires en essayant d'éviter le temps de sommeil.

Purge des demandes simultanées
On constate que lorsque les enregistrements dans FND_CONCURRENT_PROCESSES et FND_CONCURRENT_REQUESTS dépassent 50 000, vous pouvez commencer à rencontrer de sérieux problèmes de performances dans vos applications Oracle. Afin d'éviter ces problèmes, nous devons régulièrement purger les données de ces tables à l'aide d'une requête spécifique appelée "Purge Concurrent Requests And/Or Manager Data". Elle doit être programmée pour s'exécuter régulièrement. Cette requête peut être configurée pour purger les données de requête des tables FND ainsi que les fichiers journaux et les fichiers de sortie accumulés sur le disque.

Analyse des tables de dictionnaire d'Oracle Apps pour des performances élevées

Les tables Concurrent Manager peuvent se fragmenter au fil du temps, il est donc recommandé de les reconstruire dans le cadre d'une maintenance régulière
Il est également très important d'exécuter la requête Gather Table Statistics
Certaines des tables importantes sont
FND_CONCURRENT_PROCESSES
FND_CONCURRENT_PROGRAMS
FND_CONCURRENT_REQUESTS,
FND_CONCURRENT_QUEUES.

J'espère que vous aimez cet article sur Oracle Concurrent Manager .

Lire aussi
Requêtes du gestionnaire simultané :cet article contient les 30 meilleures requêtes du gestionnaire simultané pour le dépannage, la résolution, le temps d'exécution et les détails du gestionnaire simultané
ORA-01427 :consultez ceci pour la solution sur ORA-01427 :une seule ligne la sous-requête renvoie plus d'une erreur de ligne, comment la résoudre lorsque cela se produit avec Concurrent Manager
jeu de requêtes dans les applications oracle :l'ensemble de requêtes permet de soumettre régulièrement le même ensemble de requêtes à l'aide d'une seule transaction.
Questions d'entrevue de gestionnaire simultané ::Découvrez 24 questions d'entrevue de gestionnaire simultané pour vous aider dans l'entrevue EBS. Il s'agit de toutes sortes de questions sur le gestionnaire standard, le gestionnaire de services
Traitement simultané parallèle :Qu'est-ce que le PCP, comment le configurer, comment définir le moniteur interne
Oracle Concurrent Manager : Comment un système E-Business Suite Manager Process Works, Oracle Concurrent Manager, Qu'est-ce que le moniteur interne, Qu'est-ce que le gestionnaire de services et le dépannage

Cours recommandés

Voici quelques-uns des cours recommandés que vous pouvez acheter si vous souhaitez aller plus loin

Vous trouverez ci-dessous les liens vers certains des cours

Oracle DBA 11g/12c – Administration de base de données pour Junior DBA :Ce cours est bon pour les personnes qui commencent en tant que DBA junior ou qui aspirent à devenir DBA Oracle. Cela fournira une bonne compréhension des tâches de sauvegarde et de restauration et d'administration générale
Base de données Oracle :Administration d'Oracle 12C R2 RAC :Ce cours couvre l'installation, l'administration d'Oracle RAC. Un bon cours pour Oracle DBA qui souhaite mettre à niveau ses compétences pour Oracle RAC
Oracle Data Guard :Administration de base de données pour Oracle 12C R2 :Ce cours couvre l'installation, l'administration d'Oracle Dataguard. Un bon cours pour Oracle DBA qui souhaite mettre à niveau ses compétences pour Oracle Dataguard