Voici les 24 questions d'entretien de gestionnaire simultané posées dans la plupart des entretiens pour tester les compétences de travail des gestionnaires simultanés
Question 1 : Quels sont les différents types de gestionnaires simultanés ?
Répondre Il existe plusieurs types de gestionnaires simultanés. Important :
Gestionnaire interne
Gestionnaire standard.
Gestionnaire de résolution des conflits
Moniteurs internes
Gestionnaire de services
Gestionnaire de transactions
Gestionnaire personnalisé
En savoir plus sur le lien ci-dessous
Oracle Concurrent Manager
Question 2 : Qu'est-ce que le gestionnaire simultané interne ?
Répondre :Il est responsable du contrôle de tous les autres gestionnaires simultanés. Sa tâche principale est de s'assurer que tous les autres gestionnaires simultanés sont opérationnels. Il contrôle les autres gestionnaires à travers les demandes adressées au gestionnaire de service. Il démarre, arrête et redémarre également le gestionnaire de services pour tous les nœuds.
Question 3 : Qu'est-ce que le gestionnaire de résolution de conflits (CRM) ?
Réponse : Il s'occupe de résoudre les incompatibilités de programme et vérifie si une requête dans la file d'attente peut être exécutée en parallèle avec la requête en cours d'exécution. Si un programme est identifié comme exécuté seul, il empêche les gestionnaires simultanés de démarrer d'autres programmes dans le même domaine de conflit.
Question 4 : Qu'est-ce qu'un gestionnaire standard ?
Répondre :Standard Manager est le gestionnaire simultané principal. Il est toujours en cours d'exécution et peut prendre en charge le traitement de toute demande simultanée. Si aucun autre responsable n'est affecté à un programme, ce programme sera choisi par le responsable standard.
Question 5 :
Que s'est-il passé en coulisses lorsqu'une demande simultanée est soumise ?
Répondre
(1) Une fois qu'une demande simultanée est soumise par l'utilisateur, la table FND_CONCURRENT_REQUESTS est automatiquement mise à jour avec les détails de la demande. Le tableau est également mis à jour avec les informations sur la planification de la demande simultanée, qu'elle soit immédiatement planifiée ou planifiée à une heure fixe.
(2 Si la demande est incompatible/contraintes définies, une fois que le moment de l'exécution de la demande arrive, son statut est défini sur en attente/en attente. Maintenant, le gestionnaire de résolution des conflits prend en charge la demande et découvre quelles sont les incompatibilités et définit le statut en attente normal lorsque les incompatibilités sont résolues.
(3) S'il n'y a pas d'incompatibilités, une fois le moment de l'exécution de la demande arrivé, son statut est défini sur En attente/Normal
(4) TOUS les gestionnaires simultanés standard et les gestionnaires spéciaux interrogent en permanence la table FND_CONCURRENT_REQUESTS. Le travail d'un gestionnaire simultané consiste à exécuter des demandes simultanées qui sont dans la phase/le statut En attente/Normal et qu'il est qualifié pour exécuter selon ses règles de spécialisation.
(5) Processus de gestionnaire simultanés
– Agir de manière indépendante
– Sélectionner uniquement les requêtes 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 <=date système
(6) Une fois la demande traitée, la table FND_CONCURRENT_REQUESTS est mise à jour avec le statut.
Question 6 : Les utilisateurs professionnels créent l'incident selon lequel les demandes simultanées prennent beaucoup de temps à se terminer. Quelle sera votre approche pour le déboguer ?
Répondre
1) Recherchez d'abord le statut de la demande simultanée. Il peut être planifié plus tard ou il peut être en mode attente/veille ou tous les gestionnaires simultanés sont occupés à exécuter d'autres demandes. S'il est en attente/en attente, nous devons trouver le programme incompatible en cours d'exécution et en informer l'utilisateur. Souvent, les utilisateurs planifient l'exécution de la demande ultérieurement.
2) Découvrez le sid de la base de données de la demande simultanée et vérifiez qu'il attend tous les verrous. Nous allons tuer la session oracle qui bloque afin de terminer le travail
3) Nous pouvons exécuter une trace sur l'ID de la demande pour trouver le sql en cours d'exécution, puis générer le plan d'explication correspondant. Vous pouvez voir si le sid est bloqué sur un sql particulier. S'il s'agit d'un sql particulier, alors il est bon de vérifier les statistiques de la table concernée. Nous pouvons rechercher une opportunité de réglage pour cette requête
4) Nous pouvons vérifier les paramètres avec lesquels la requête est exécutée. (Par exemple, une fois qu'un utilisateur est venu en disant que la demande n'imprime pas la sortie. En vérifiant les choses possibles, on s'est rendu compte qu'il avait planifié la demande avec des copies d'impression =0.)
Question 7 : Que se passe-t-il lorsque le gestionnaire simultané interne décède brutalement ? Tous les managers sont-ils également tués immédiatement après ?
Répondre
Non TOUS les gestionnaires standard continuent de fonctionner et d'exécuter la demande. si le responsable interne décède, les demandes de contrôle de la file d'attente ci-dessous ne sont pas exécutées
a) Démarre tous les autres processus.
b) Exécute les "demandes de contrôle" soumises par l'administrateur.
c) Activer/Désactiver/Abandonner le gestionnaire simultané
d) Terminer la demande simultanée
e ) Surveille les processus, en redémarrant ceux qui ont échoué.
f) Définit le nombre cible de processus pour chaque service en fonction du quart de travail actuel.
Question 8 : Le responsable interne exécute-t-il ou planifie-t-il une demande pour lui-même ?
Répondre
Non, le responsable interne n'exécute ni ne planifie aucune demande. Cela n'a rien à voir avec la planification des demandes ou le choix du gestionnaire qui exécutera une demande particulière. Sa fonction est uniquement d'exécuter des requêtes de "contrôle de file d'attente"
a) Démarre tous les autres processus.
b) Exécute les "demandes de contrôle" soumises par l'administrateur.
c) Activer/Désactiver/Abandonner le gestionnaire simultané
d) Terminer la demande simultanée
e ) Surveille les processus, en redémarrant ceux qui ont échoué.
f) Définit le nombre cible de processus pour chaque service en fonction du quart de travail actuel.
Question 9 : Comment traiter davantage de demandes simultanées en parallèle ?
Répondre
On peut augmenter les processus cibles du gestionnaire concurrent afin d'augmenter le parallélisme. Cela peut être fait en utilisant le formulaire de définition du gestionnaire simultané ou via une mise à jour directe depuis sqlplus
Question 10 : Si le gestionnaire interne tombe en panne, dois-je tuer tous les gestionnaires avant de redémarrer le gestionnaire interne ?
Répondre
Non, si le manager interne tombe en panne, vous n'avez pas besoin de tuer tous les managers. Vous pouvez simplement démarrer le gestionnaire interne en utilisant startmgr.
Question 11 :Quels sont les problèmes que vous avez rencontrés lors de la fermeture des applications ?
Répondre
Lors de la fermeture d'une application, le gestionnaire simultané ne s'arrête généralement pas car certaines des autres demandes peuvent être en cours d'exécution. Nous verrons quelles sont les requêtes simultanées exécutées en interrogeant fnd_concurrent_requests, fnd_concurrent_program_vl, v$session, v$process et v$sqltext.
Si cette requête ne fait qu'une instruction select, nous tuerons ces requêtes, sinon, nous vérifierons le temps qu'il faudra pour terminer en interrogeant les exécutions précédentes de cette requête, puis nous déciderons quoi faire.
Question 12 : Que sont les moniteurs internes ?
Réponse : Les moniteurs internes sont utilisés spécifiquement dans PCP pour permettre le basculement d'ICM vers d'autres nœuds de niveau intermédiaire disponibles.
a) Placez un moniteur interne sur n'importe quel nœud où l'ICM peut démarrer en cas de panne.
b) Les moniteurs internes sont amorcés sur chaque nœud enregistré par défaut.
c) Si l'ICM tombe en panne, le moniteur interne tentera de démarrer un nouvel ICM sur le nœud local.
d) Si plusieurs ICM sont démarrés, seul le premier restera actif. Les autres sortiront gracieusement.
Question 13 : Puis-je supprimer le gestionnaire simultané ?
Réponse :
Oui, vous pouvez supprimer n'importe quel gestionnaire simultané. Pour supprimer, recherchez le gestionnaire dans le formulaire de gestionnaire simultané défini, puis supprimez la ligne.
La suppression des gestionnaires simultanés prédéfinis n'est pas recommandée et ne doit jamais être effectuée. La suppression peut entraîner une instabilité dans le système.
Question 14 : Comment savoir quel fichier de trace est créé pour la requête particulière ?
Répondre
Vous pouvez trouver la même chose en utilisant le script ci-dessous. La trace sera située à l'emplacement udump du serveur de base de données.
prompt
accept request prompt ‘Please enter the concurrent request id for the appropriate concurrent program:’
prompt
column traceid format a8
column tracename format a80
column user_concurrent_program_name format a40
column execname format a15
column enable_trace format a12
set lines 80
set pages 22
set head off
SELECT ‘Request id: ‘||request_id, ‘Trace id: ‘||oracle_Process_id, ‘Trace flag: ‘||req.enable_trace, ‘Trace Name: ‘||dest.value||’ ‘||lower(dbnm.value)||’ora’||oracle_process_id||’.trc’, ‘Prog. Name: ‘||prog.user_concurrent_program_name, ‘File name: ‘||execname.execution_file_name||execname.subroutine_name , ‘Status :’||decode(phase_code, ‘R’, ‘Running’)||’ ‘||’-‘||decode(status_code, ‘R’, ‘Normal’), “SID Serial: “||ses.sid||” , “||ses.serial#, “Module : “||ses.module
from fnd_concurrent_requests req,
v$session ses, v$process proc,
v$parameter dest, v$parameter dbnm,
fnd_concurrent_programs_v1 prog,
fnd_executables execname
where req.request_id = &request
and req.oracle_process_id=proc.spid(+)
and proc.addr = ses.paddr(+)
and dest.name=’user_dump_dest’
and dbnm.name=’db_name’
and req.concurrent_program_id =
prog.concurrent_program_id
and req.program_application_id =
prog.application_id
and prog.application_id =
execname.application_id
and
prog.executable_id=execname.executable_id;
Top 30 des requêtes de gestion simultanée les plus utiles
Question 15 : Expliquez-vous comment fonctionne le traitement simultané parallèle (PCP) ?
Répondre
En cas de traitement simultané parallèle, tous les gestionnaires se voient attribuer un nœud principal et un nœud secondaire. Les gestionnaires sont démarrés dans leur nœud principal par défaut. En cas de panne d'un nœud ou d'une panne d'instance Oracle, tous les gestionnaires simultanés de ce nœud sont basculés vers leurs nœuds secondaires. Une fois que le nœud principal est à nouveau disponible, les gestionnaires simultanés sur les nœuds secondaires sont migrés vers le nœud principal. Au cours du processus de migration, un gestionnaire peut être réparti sur les nœuds principal et secondaire.
En cas de traitement simultané parallèle, il peut arriver que dans un nœud où le traitement simultané parallèle est configuré, l'instance Oracle soit ou non en cours d'exécution. Le nœud qui n'exécute pas Oracle, les gestionnaires simultanés se connectent via Net8 à un nœud qui exécute Oracle.
Le gestionnaire simultané interne peut s'exécuter sur n'importe quel nœud et peut activer et désactiver les gestionnaires simultanés sur tous les nœuds. Étant donné que le gestionnaire de simultanéité interne doit être actif à tout moment, il a besoin d'une tolérance élevée aux pannes. Pour fournir cette tolérance aux pannes, le traitement simultané parallèle utilise des processus de surveillance internes. Le travail du processus de surveillance interne consiste à surveiller en permanence le gestionnaire interne et à le démarrer en cas d'échec. Un seul processus de surveillance interne peut être actif sur un seul nœud. Vous décidez quels nœuds ont un processus de surveillance interne lorsque vous configurez votre système. Vous pouvez également affecter à chaque processus de surveillance interne un nœud principal et un nœud secondaire pour assurer la protection contre le basculement. Les processus de surveillance interne, comme les gestionnaires simultanés, peuvent être affectés à des quarts de travail et sont activés et désactivés par le gestionnaire simultané interne.
Traitement simultané parallèle
Question 16 : Dans quelles circonstances devez-vous renvoyer le gestionnaire simultané ?
Réponse :Il peut y avoir de nombreuses situations dans lesquelles vous devez renvoyer le gestionnaire simultané
a) Lorsque vous modifiez la définition des imprimantes
b) Lorsque vous modifiez les variables d'environnement. Supposons que vous ayez modifié les variables APPLTMP et APPLPTMP.
c) Lorsque toutes les demandes sont en attente et suspendues et qu'aucun traitement n'est en cours
d) l'application du correctif nécessite le rebond du CM
e) Nous avons de nombreux blocages globaux dans le système en raison de blocages par plusieurs gestionnaires simultanés et d'autres processus
Question 17 : Quelles sont les raisons pour lesquelles un gestionnaire simultané se bloque ?
Réponse :
Le gestionnaire simultané se bloque pour de nombreuses raisons. En voici quelques-unes :
– Travaux de longue durée
– Le gestionnaire interne a été activé par quelqu'un d'autre que le propriétaire du système d'application
– Le système de fichiers du système d'exploitation est plein
– Impossible de créer le fichier journal
– Vous avez fermé le gestionnaire interne, mais il contient en fait un numéro
– La base de données se bloque peut-être parce que les fichiers journaux d'archivage ont été remplis
– Les demandes en attente/en attente sont trop nombreuses
Question 18 : Comment pouvons-nous activer/désactiver le gestionnaire de résolution des conflits ?
Réponse : Cela peut être fait en utilisant les options de profil « Simultané :Utiliser ICM ». Réglez-le sur "Y" pour activer le gestionnaire de résolution des conflits. Pour le désactiver, définissez l'option de profil sur "N".
Question 19 : Que sont les gestionnaires de transactions ?
Réponse : Les gestionnaires de transactions fournissent un traitement de travail synchrone en surveillant en permanence un canal SGBD pour les demandes provenant d'une application côté client. Le travail d'un gestionnaire de transactions consiste à traiter ce travail immédiatement et à renvoyer les informations au client à l'aide du canal.
a) Les gestionnaires de transactions fournissent un traitement synchrone des tâches
b) Un client demande à un gestionnaire de transactions spécifique d'exécuter un programme et attend les résultats de ce programme
c) Les programmes des équipes de produit sont directement liés à les exécutables du gestionnaire de transactions
d) PO, CRP, INV, AR et OE expédient tous les gestionnaires de transactions
Question 20 : Comment fonctionne le mécanisme d'affichage des fichiers journaux et de sortie depuis le navigateur ?
Répondre
La séquence des événements est la suivante :
1. Un utilisateur au sein d'une session d'applications demande à afficher un fichier de déconnexion ou de sortie.
2. Le navigateur reçoit la demande et génère le programme CGI FNDWRR.exe
3. FNDWRR.exe se connecte à la base de données et interroge FND_CONCURRENT_REQUESTS pour découvrir sur quel nœud les fichiers de cette requête sont stockés.
4. FNDWRR.exe construit le nom de service pour le serveur de fichiers sur ce nœud. Et fait l'appel tns pour contacter l'écouteur pour ce nom de service.
5. L'écouteur répond en générant l'exécutable FNDFS local, comme défini dans son fichier listener.ora. Désormais, FNDFS et FNDWRR.exe peuvent communiquer directement à l'aide d'appels RPC.
6. FNDWRR.exe demande à FNDFS de transférer le fichier sélectionné par l'utilisateur.
7. FNDFS transfère le contenu du fichier dans un répertoire de fichiers temporaire sur le nœud du serveur Web.
8. Le serveur Web affiche le contenu du fichier à l'utilisateur.
Question 21 : Pourquoi le gestionnaire simultané place-t-il un programme simultané dans une file d'attente ? Pourquoi le gestionnaire ne laisse-t-il pas simplement le programme s'exécuter ?
Réponse : Parce qu'à un moment donné, un gestionnaire simultané ne peut pas exécuter plus de 10 programmes simultanément. Ce chiffre de 10 est configurable bien sûr. Tout d'abord, le gestionnaire place un programme soumis dans une file d'attente, ensuite, le gestionnaire vérifie s'il y a un créneau disponible (c'est-à-dire moins de 10 programmes sont actuellement en cours d'exécution). Si un emplacement est trouvé disponible, le gestionnaire de simultané exécute alors le programme, ou bien il maintient le programme concurrent dans une file d'attente avec le statut En attente.
Question 22 : Que faire si une demande est inactive/sans gestionnaire
Réponse : Ce sont des questions assez délicates
a) Assurez-vous qu'il y a au moins un gestionnaire actif avec des règles de spécialisation qui autorisent le programme.
b) Si vous avez confirmé le point précédent, le problème peut être obsolète Vue des demandes des travailleurs
– La vue est utilisée en interne pour mapper les demandes aux responsables
– La vue est régénérée lorsque les responsables sont créés ou que les règles de spécialisation sont modifiées
c) Vous pouvez régénérer manuellement la vue
FNDLIBR FND FNDCPBWV apps/apps SYSADMIN 'System Administrator' SYSADMIN
Question 23 : Qu'est-ce que les gestionnaires de services ?
Réponse : 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 certaines fonctions, telles que le démarrage d'un processus de gestion simultanée, sur un nœud de niveau intermédiaire, il effectue des appels de contrôle de procédure à distance (RPC) vers l'écouteur d'applications sur ce nœud pour démarrer le Gestionnaire de services. Une fois que le gestionnaire de services a été démarré et initialisé, l'ICM communique directement avec le SM via RPC, lui donnant des informations pour gérer les services sur ce nœud. Le SM 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). L'écouteur TNS génère Service Manager pour qu'il s'exécute en tant qu'agent d'ICM pour le nœud local
Le Service Manager est démarré par ICM à la demande lorsque cela est nécessaire. 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 quittent également.
Question 24 : Qu'est-ce qui est exécuté par ICM Process Monitor ?
Réponse : L'ICM lui-même et chaque processus généré par l'ICM ont une entrée dans FND_CONCURRENT_PROCESSES et contiennent un verrou DBMS nommé de manière unique.
Le verrou unique de l'ICM a le format FNDCPLK_ICM. Ce verrouillage de session de base de données est la méthode par laquelle ICM garantit à chaque cycle PMON que les processus de gestionnaire et de service sont toujours actifs. Si l'ICM peut obtenir le verrou de session SGBD d'un processus, l'ICM démarre un nouveau processus pour ce gestionnaire ou ce service.
C'est la raison pour laquelle vous verrez souvent des entrées comme un processus mort trouvé, démarrant un nouveau processus dans les fichiers journaux ICM.
Articles connexes pour le gestionnaire simultané
Isolation des programmes simultanés post-mise à niveau vers une file d'attente de gestionnaire distincte dans R12.2 :comment isoler le simultané demandé soumis par la mise à niveau vers un gestionnaire simultané distinct afin que le traitement simultané régulier ne soit pas affecté
comment envoyer la sortie du programme simultané via e-mail :option de livraison pour la sortie du programme simultané dans la version Oracle EBS R12.
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.
CP Analyzer :le CP Analyzer examine les configurations CP et les compare aux meilleures pratiques d'Oracle
Simultané :phase et statut de la demande :toutes les informations sur la phase et le statut de la demande simultanée. La signification est dérivée pour chaque combinaison.
ORA-01427 :vérifier ceci pour la solution sur ORA-01427 :la sous-requête à une seule ligne renvoie plus d'une erreur de ligne, comment la résoudre lorsqu'elle se produit avec Concurrent Manager
Priorité pour le programme simultané :ce message a une description détaillée ription sur la modification de la priorité pour le programme simultané ou l'utilisateur ou la demande pour résoudre les problèmes d'exécution des rapports critiques de l'utilisateur
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
Guide d'examen tout-en-un OCA/OCP Oracle Database 12c (examens 1Z0-061, 1Z0-062 et 1Z0-063)
Manuel Oracle Database 12c DBA (Oracle Press)
Scripts tout-en-un Oracle DBA – Un guide que chaque DBA doit avoir :Scripts Oracle dba collection utilisée quotidiennement par les administrateurs de bases de données experts. Doit avoir des scripts dba pour vos activités quotidiennes !