Quelques fois on est obligé d'aller valider que nos serveurs reports sont bien partis, dans ce cas, je vais tout simplement montrer comment le faire dans le cas d'un Standalone Report Server.
Pour ce faire on a deux méthodes, soit passer par Weblogic ou faire la vérification avec le Node Manager. Faites attention aux ports de mon exemple si jamais vous les avez configuré autrement lors de l'installation.
Weblogic :
$ORACLE_HOME/oracle_common/common/bin/wlst.sh
connect("weblogic","VotreMdP","NomServeur.Nomdomaine:7001")
domainRuntime()
cd('/SystemComponentLifeCycleRuntimes/')
cd('NomVotreServeur')
cmo.getState()
exit()
NodeManager :
$ORACLE_HOME/oracle_common/common/bin/wlst.sh
nmConnect('weblogic','VotreMdP','NomServeur.Nomdomaine','5556','NomVotreDomaine','PathDomainInst')
nmServerStatus(serverName='NomVotreServeur',serverType='ReportsServerComponent')
exit()
Pour ce dernier, ce n'est pas si évident à comprendre, pour que ce soit plus claire, je vais vous donner un petit exemple :
$ORACLE_HOME/oracle_common/common/bin/wlst.sh
nmConnect('weblogic','******','srvtest.client.com','5556','frdomaintest1','/abc1/oracle/monpath/config/domains/frdomainclient')
nmServerStatus(serverName='srvrep01',serverType='ReportsServerComponent')
Dans les deux cas, si le serveur est en exécution, il va afficher RUNNING, sinon il affichera SHUTDOWN.
vendredi 12 juillet 2019
mardi 9 juillet 2019
Des fichiers traces trop volumineux à chaque sauvegarde RMAN ?
Le manque d'espace sur un serveur est une problème qu'on devrait avoir très rarement, des outils de surveillance (voir OEM, Nagios, etc) vont nous permettre d'être avertis de tout consommation excessive d'espace sur nos serveurs, cependant cela peut se produire quand même malgré nos précautions.
Pour commencer on va vous placer dans le contexte :
Bases de données : Oracle 12cR1 + PSU Avril 2019
Système d'exploitations : Solaris 11 - 64 bits
Et...justement c'est ça le problème qu'on a eu chez un de nos clients, on a vu notre espace de l'ORACLE_HOME remplir assez vite dans une seule journée à cause des fichiers de traces trop volumineux.
Selon nos politiques de conservations des logs et des traces on était correct, cependant avoir de gros fichiers de plusieurs Go dans la même journée dans l'espace de quelques heures ce n'est pas habituel.
En feuillant un peu j'ai remarqué que ces traces sont plutôt reliés à nos sauvegardes RMAN qui commençaient à inscrire tout, mais absolument tout ce qu'il faisait pendant la sauvegarde, et avec une base de données assez grande on peut comprendre que le fichier ou fichiers résultants peut être assez grand.
Voici un exemple du contenu d'un des fichiers trace :
Et cela continue, et continue :
le fichier de trace a plusieurs Go et il peut être divisé en plus en plusieurs fichiers pour la même sauvegarde, comme c'était notre cas.
Apparemment le dernier PSU d'avril 2019 nous a apporté ces petits problèmes pour notre version de base de données.
Sur le site d'Oracle, après quelques recherches, il recommande d'installer un patch mais qui pour le moment est disponible juste pour 12cR2, le contournement reste notre seule solution pour le moment.
Selon la note "RMAN Generating Trace File at Every Execution 2323240.1"
On devrait venir faire une modification dans le paramètre events pour éviter que la base de données continue de nos générer ces gros fichiers, voici la solution de contournement :
On peut le faire en mémoire et cela va bien fonctionne :
alter system set events 'trace[krb.*] disk disable, memory disable' ;
Pour quelque chose plus permanent, il faudrait le faire dans le spfile :
alter system set event = 'trace[krb.*] disk disable, memory disable' scope = spfile;
jeudi 4 juillet 2019
OFM 12c - JDK 1.8 - Standalone report server ne parte pas
Lors d'une installation de OFM 12c (12.2.1.3) que je viens de réaliser, j'ai dû configurer quelques Standalone Reports Server mais malheureusement j'ai rencontré quelques petits problèmes.
Mise en contexte :
- Système d'exploitation Solaris 11 - 64 bits
- OFM12c - 12.2.1.3
- JDK : 1.8.0_212
Une fois l'installation et configuration du domaine terminées, j'ai continué avec la création d'un standalone Report server afin de permettre une meilleure gestion du même.
Pour ce faire, selon la remcommandation d'Oracle il faut préalablement arrêter le WLS_REPORTS.
$DOMAIN_HOME/bin/stopManagedWebLogic.sh
WLS_REPORTS
Par la suite, il faut se servir de WebLogic Scripts et pourtant on doit ouvrir une connexion:
cd
$ORACLE_HOME/oracle_common/common/bin
./wlst.sh
Ici, vous devez remplacer les paramètres par les entrées correspondantes :
connect("weblogic","weblogic_password","ServerName.DomainName:7001")
On va commencer par créer le ReportsTool, on peut choisis le nom, mais le deuxième paramètre correspond au nom choisi lors de votre installation, s'il n'a pas été modifié -comme c'est mon cas- il sera AdminServerMarchine :
createReportsToolsInstance(instanceName='reptools1',machine='AdminServerMachine')
Si jamais vous avez commis une erreur, vous pouvez toujours le supprimer :
deleteReportsToolsInstance(instanceName='reptools1')
Par la suite, on va créer le standalone Report server, dans ce cas je vais le nommer : srwitst
createReportsServerInstance(instanceName='srwitst',machine='AdminServerMachine')
Comme on peut voir on n'a pas d'erreur au moment de la création, les répertoires sont créés, et tout semble correct.
Donc, on repart WLS_REPORTS et bien sûr le nouveau serveur srwitst que je viens de créer :
$DOMAIN_HOME/bin/startComponent.sh srwitst
Encore une fois, aucune erreur. Cependant si je commence à valider les processus je ne vois pas des Engines partis.
ps -ef | grep srwitst
Va me ramener le processus en mémoire, par contre :
ps -ef | grep rwEng
N'affiche pas de processus.
Pire encore, lorsque je viens faire ma validation avec wlst (Bien entendu, j'ai caché quelques informations )
mais seulement 2 secondes après, la même commande m'affiche SHUTDOWN, et il commence une boucle de RUNNING et SHUTDOWN interminable.
Bref, on a un problème. Pour tout confirmer je vais faire un dernier test et cela m'a donné la piste de la solution.
Le problème semble relié à une "Cryptographic operation" , en feuillant sur le site de support d'Oracle je me suis rendu sur la note :
- 12.2.1.3.0: Standalone Report Server Restarted Continuously By Node Manager (Doc ID 2400542.1)
Laquelle va m'envoyer sur le lien pour télécharger les jarfiles reliés, en bref, avec Java 1.8, il faut remplacer deux fichiers jar afin d'éviter ces problèmes, donc, il faut les remplacer dans notre jdk et dans le jdk de l'installation ($ORACLE_HOME/oracle_common/jdk/jre/lib/security) :
- local_policy.jar
- US_export_policy.jar
Une fois les fichiers remplacés, on peut repartir le WLS_REPORTS et mon srwitst dans problème.
Inscription à :
Articles (Atom)