Vérifiez le statut d'un Standalone Report Server - OFM 12c

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.

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;

Bien évidemment, cette dernière alternative est la plus recommandée.

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.

Test de FailOver ( DataGuard )

Notre client voulait faire un essai de relève qui allait s'approcher le plus possible à une vraie situation de "Disaster Recovery", pour ce faire, un FAILOVER serait forcé pendant les essais mais sans impacter la base de données primaire.

Celle-ci, est une petite bases de données mais cela va vous donner une bonne idée des travaux :


ASM sur Serveur StandBy :
-------------------------
Valider l'espace disponible sur le Dsigroup
ASMCMD> lsdg *MYDB*
State    Type    ...  Total_MB  Free_MB  ...  Name
MOUNTED  EXTERN  ...     30700    23615  ...  FLASMYDBD/
MOUNTED  EXTERN  ...    102380    66597  ...  DATAMYDBD/


StandBy Database :
------------------

SELECT DATABASE_ROLE FROM V$DATABASE ;
DATABASE_ROLE
----------------
PHYSICAL STANDBY


SHOW PARAMETER RECOVERY
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      +FLASMYDBD
db_recovery_file_dest_size           big integer 15G


Valider la synchronisation de la base de données STANDBY
LOGS             TIME                  SEQUENCE# INCARNATION# 
---------------- -------------------- ---------- ------------ 
LAST APPLIED  :  11-FEB-2019 13:40:34      62228            2 
LAST RECEIVED :  11-FEB-2019 14:00:32      62229            2 

Arrêter l'apply :
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;  


Créer un RESTORE POINT GUARANTEE :
CREATE RESTORE POINT TEST_FAILOVER GUARANTEE FLASHBACK DATABASE; 


Vérifier le RESTORE POINT :
COL NAME FORMAT A20
COL SCN  FORMAT A15
COL TIME FORMAT A20
SELECT NAME, TO_CHAR(SCN) SCN, TO_CHAR(TIME,'DD/MM/YYYY HH24:MI') TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE/1024/1024 MO
FROM V$RESTORE_POINT 
WHERE GUARANTEE_FLASHBACK_DATABASE = 'YES' ;
 
NAME                 SCN             TIME                 DATABASE_INCARNATION# GUA         MO
-------------------- --------------- -------------------- --------------------- --- ----------
TEST_FAILOVER        9811893079035   11/02/2019 14:20                         2 YES        300


Primary Database :
------------------
Créer un décalage des SCN entre la Primaire et la standBy :
ALTER SYSTEM ARCHIVE LOG CURRENT;
ALTER SYSTEM ARCHIVE LOG CURRENT;
ALTER SYSTEM ARCHIVE LOG CURRENT;

Vérifier la configuration de destination :
SHOW PARAMETER LOG_ARCHIVE_DEST
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest                     string
log_archive_dest_1                   string      LOCATION=+FLASMYDBD/...
log_archive_dest_10                  string
...
...
log_archive_dest_2                   string      service="SMYDB", LGWR AS...
...
...

SHOW PARAMETER LOG_ARCHIVE_DEST_STATE_2
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_2             string      ENABLE


Empêcher l'envoie des archives vers la StandBy :

ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;


SHOW PARAMETER LOG_ARCHIVE_DEST_STATE_2
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_2             string      DEFER


StandBy Database :
------------------
Valider le type de controlfile :
SELECT CONTROLFILE_TYPE FROM V$DATABASE; 
CONTROL
-------
STANDBY


Convertir la base de données en Bd Primaire :
ALTER DATABASE ACTIVATE STANDBY DATABASE;


Valider que le type de controlfile ait changé : 
SELECT CONTROLFILE_TYPE FROM V$DATABASE; 
CONTROL
-------
CURRENT

Ouvrir la bases de données :
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE; 
ALTER DATABASE OPEN;

Valider le Rôle de la base de données :
SELECT DATABASE_ROLE FROM V$DATABASE ;
DATABASE_ROLE
----------------
PRIMARY



StandBy Database :
------------------
Procéder aux essais , il faut noter que tous les objets crées ou toutes les modifications vont disparaître après cet essai.

SQL> CREATE TABLE TOTO ( COL1 VARCHAR2 (100)); 
Table created. 

SQL> INSERT INTO TOTO VALUES ( 'Testing Failover - FlashBack'); 
1 row created. 

SQL> commit; 
Commit complete.


StandBy Database :
------------------
Une fois les essais terminés, il faut revenir en arrière .

Repartir la base de données :
STARTUP MOUNT FORCE;

Exécuter le Flashback :
FLASHBACK DATABASE TO RESTORE POINT TEST_FAILOVER ;

Valider le type de controlfile :
SELECT CONTROLFILE_TYPE FROM V$DATABASE; 
CONTROL
-------
BACKUP

Convertir la base de données à Physical StandBy :
ALTER DATABASE CONVERT TO PHYSICAL STANDBY;  
STARTUP MOUNT FORCE;  
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION ; 

Valider le type de controlfile :
SELECT CONTROLFILE_TYPE FROM V$DATABASE; 
CONTROL
-------
STANDBY


Primary Database :
------------------
Activer l'envoi des archives :
ALTER SYSTEM ARCHIVE LOG CURRENT;  
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE; 

SHOW PARAMETER LOG_ARCHIVE_DEST_STATE_2
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_2             string      ENABLE


StandBy Database :
------------------
Ouvrir la base de donnes en Read-only pour confirmer que les objets crééer ont disparus

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;  
ALTER DATABASE OPEN READ ONLY;  

SQL> SELECT * FROM TOTO;  
SELECT * FROM TOTO
  *
ERROR at line 1:
ORA-00942: table or view does not exist


Réactiver la synchronisation :
STARTUP FORCE MOUNT;  
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION ; 

S'assurer que la bases de données continue à synchroniser :
LOGS             TIME                  SEQUENCE# INCARNATION# NAME
---------------- -------------------- ---------- ------------ 
LAST APPLIED  :  11-FEB-2019 14:32:25      62238            2 
LAST RECEIVED :  11-FEB-2019 14:32:28      62239            2 


Supprimer le Restore Point :

COL NAME FORMAT A20
COL SCN  FORMAT A15
COL TIME FORMAT A20
SELECT NAME, TO_CHAR(SCN) SCN, TO_CHAR(TIME,'DD/MM/YYYY HH24:MI') TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE/1024/1024 MO
FROM V$RESTORE_POINT 
WHERE GUARANTEE_FLASHBACK_DATABASE = 'YES' ;

NAME                 SCN             TIME                 DATABASE_INCARNATION# GUA         MO
-------------------- --------------- -------------------- --------------------- --- ----------
TEST_FAILOVER        9811893079035   11/02/2019 14:20                         2 YES        600


DROP RESTORE POINT TEST_FAILOVER ;  

Automatic Big Table caching ?

On sait tous que Oracle se sert de sa mémoire pour placer les donnée et faciliter de cette manière l'accès aux données, mais on sait aussi que dans la plupart des cas c'est impossible de placer la base de données au complet en mémoire.

On sait aussi que des options keep et cache existent depuis un bon moment, mais maintenant Oracle propose une alternative intéressante et utile de faire ça d'une façon automatique.

Le but de cette fonctionnalité c'est de placer les tables assez grandes où des FULL SCAN est utilisé fréquemment. Ce "fréquemment" est appelé dans l'argot d'Oracle : Température  

Pour commencer il faudrait savoir c'est quoi une grosse table pour Oracle, pour le savoir il faudrait regarder 2 paramètres :

Le _small_table_threshold représente normalement le 2% de votre paramètre _db_block_buffers

SET PAGESIZE 500
COL KSPPINM FORMAT A40
COL KSPPSTVL FORMAT A30
SELECT KSPPINM, KSPPSTVL
  FROM X$KSPPI A, X$KSPPSV B
 WHERE A.INDX=B.INDX AND SUBSTR(KSPPINM,1,1) = '_' AND 
       KSPPINM IN ('_small_table_threshold','_db_block_buffers') ;

KSPPINM                                  KSPPSTVL
---------------------------------------- ------------------------------
_db_block_buffers                        528288
_small_table_threshold                   10565

Dans ce cas, une grosse table devra dépasser la valeur indiquée dans le _small_table_threshold pour être pris en compte par cette fonctionnalité d'Oracle.

Comme les tables seront placées en mémoire et on ne veut pas que toute notre mémoire soit utilisé pour ces objets en question, on a un paramètre à modifier afin de dire à notre base de données le maximum de mémoire -en pourcentage- à réserver pour ces objets.

SHOW PARAMETER DB_BIG_TABLE_CACHE_PERCENT_TARGET
NAME                                 TYPE        VALUE 
------------------------------------ ----------- ----- 
db_big_table_cache_percent_target    string      0     

En suite, deux vues vont nous donner des informations sur les objets placés dans cette portion de mémoire réservée : 

SET LINESIZE 400
SELECT * FROM V$BT_SCAN_CACHE;
BT_CACHE_ALLOC BT_CACHE_TARGET OBJECT_COUNT MEMORY_BUF_ALLOC MIN_CACHED_TEMP     CON_ID
-------------- --------------- ------------ ---------------- --------------- ----------
0               0            0                0            1000          0

SELECT * FROM V$BT_SCAN_OBJ_TEMPS;

aucune ligne sélectionnée

Passons à le configurer : Je vais réserver 40% de mon Buffer Cache pour placer les grosses tables qui font de FULL SCAN assez souvent.

ALTER SYSTEM SET DB_BIG_TABLE_CACHE_PERCENT_TARGET = 30;

Seulement comme exemple, je vais prendre une de mes tables pour bien valider qu'elle pourrait -en conditionnel car on ne peut pas les choisir avec cette fonctionnalité- se placer en mémoire :

SELECT BLOCKS , ROUND(BYTES/1024/1024/1024,2) GB
  FROM DBA_SEGMENTS
 WHERE SEGMENT_NAME = 'REVISIONS';
BLOCKS         GB
---------- ----------
155648       1.19


Je vais forcer -pour le test- un FULL SCAN : 


SELECT * FROM UCM.REVISIONS ;

Par la suite : 

SELECT * FROM V$BT_SCAN_CACHE;

BT_CACHE_ALLOC BT_CACHE_TARGET OBJECT_COUNT MEMORY_BUF_ALLOC MIN_CACHED_TEMP     CON_ID
-------------- --------------- ------------ ---------------- --------------- ----------
    .300028456              30            3           165308            1000          0

La colonne BT_CACHE_TARGET affiche le 30% que j'avais assigné. 

La colonne OBJECT_COUNT me dit combien d'objets profitent de cette configuration.

Après quelques minutes, on peut voir d'autres objets profiter de cette mémoire réservée : 

COL OWNER FORMAT A15 
COL OBJECT_NAME FORMAT A30
SELECT A.* , B.OWNER, B.OBJECT_NAME 
  FROM V$BT_SCAN_OBJ_TEMPS A, DBA_OBJECTS B 
 WHERE A.DATAOBJ# = B.DATA_OBJECT_ID 
 ORDER BY POLICY DESC ;
  
 TS#   DATAOBJ# SIZE_IN_BLKS TEMPERATURE POLICY    CACHED_IN_MEM     CON_ID OWNER  OBJECT_NAME
---- ---------- ------------ ----------- --------- ------------- ---------- ------ -----------
  15     216940       128685        1000 MEM_PART          23670          0 UCM    DOCMETA
  15     217093        96208        6000 MEM_ONLY          96208          0 UCM    REVCLASSES
  15     216946       155624       55380 MEM_ONLY         155624          0 UCM    REVISIONS

La colonne SIZE_IN_BLKS devrait être proche du nombre de blocks de la table en question si jamais elle est placé en mémoire.

Dans ce cas la colonne POLICY va nous dire que la table est placé complètement en mémoire, par contre on peut voir aussi que la table DOCMETA, laquelle est placé partiellement en mémoire. 

Les possibles valeurs : 

MEM_ONLY : This object will be fully cached in memory.

MEM_PART : This object will be partially cached in memory and some portion will remain on disk and will not be cached.

DISK : this object will not be cached in memory or flash for the scan at all.

INVALID : The caching policy is not valid.

Comme on peut voir, on n'a pas toujours la garantie de placer nos objets au complet en mémoire, cependant avec le 40% que j'ai mis, j'ai réussi à placer ma table REVISIONS en mémoire, bien entendu, cette fonctionnalité a plusieurs avantages cependant le fait de ne pas pouvoir choisir l'objet désiré et le placer en mémoire, peut ne pas être la meilleure solution dans quelques cas.  

Probablement dans ce cas l'option IN-MEMORY serait plus adéquate selon vos besoins.