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.

TCPS - BLOB - Problème de communication

L'autre jour chez un de mes clients, on nous avait dit qu'on avait quelques  problèmes avec des sessions gelées au moment de déposer un fichier BLOB sur la base de données en passant par une connexion sécurisée. 


Base de données : 11.2.0.4
Système d'exploitation de la Bd : Solaris 10
Client Oracle  : 11g (11.2.0.4) sur Windows Server 64 bits


Toutes les autres activités en TCPS se faisaient sans problème, mais c'était juste au moment d'essayer de déposer un fichier sur la base de données qu'on avait le problème. 

En activant le trace sur le client 11g au niveau du "sqlnet.ora" (Voir les paramètres ci-dessous)

TRACE_UNIQUE_CLIENT=ON
TRACE_LEVEL_CLIENT=16
TRACE_DIRECTORY_CLIENT=C:\Temp
TRACE_FILE_CLIENT=TRC_CLT
TRACE_FILELEN_CLIENT=40960
TRACE_FILENO_CLIENT=2
TRACE_TIMESTAMP_CLIENT=ON
ADR_BASE=OFF
DIAG_ADR_ENABLED=OFF

J'ai demandé au responsable de lancer un autre test afin d'obtenir le fichier de trace.

Une fois obtenu, en feuillant dans le fichier de trace je me suis aperçu que la lecture du wallet se faisait sans problème et que l'établissement de la connexion sécurisée entre le serveur et client se faisait aussi, cependant j'ai remarqué aussi les lignes ci-dessous, en particulier de la ligne en surbrillance, qui montre un message d'erreur :

...

[000001 16-OCT. -2018 11:40:15:736] ntt2err: exit
[000001 16-OCT. -2018 11:40:15:736] nttrd: socket 712 had bytes read=0
[000001 16-OCT. -2018 11:40:15:736] nttrd: exit
[000001 16-OCT. -2018 11:40:15:736] [Raw read] length = 0
[000001 16-OCT. -2018 11:40:15:736]  <read error -6993>
[000001 16-OCT. -2018 11:40:15:736]  read 0 bytes. cicerr = -2130640891
[000001 16-OCT. -2018 11:40:15:736]  read 0 bytes. error = 28861
[000001 16-OCT. -2018 11:40:15:736] nzos_Read: exit
[000001 16-OCT. -2018 11:40:15:736] ntznzosread: encountered "wouldblock" error
[000001 16-OCT. -2018 11:40:15:736] ntctst: size of NTTEST list is 1 - not calling poll
[000001 16-OCT. -2018 11:40:15:736] sntseltst: Testing for DATA on socket 712
[000001 16-OCT. -2018 11:40:16:018] sntseltst: FOUND: read request on socket 712
[000001 16-OCT. -2018 11:40:16:018] nzos_Read: entry
[000001 16-OCT. -2018 11:40:16:018]  reading 8208 bytes
[000001 16-OCT. -2018 11:40:16:018] nttrd: entry
[000001 16-OCT. -2018 11:40:16:018] nttrd: socket 712 had bytes read=5
[000001 16-OCT. -2018 11:40:16:018] nttrd: exit
[000001 16-OCT. -2018 11:40:16:018] [Raw read] length = 5
...

Le détail sur le code d'erreur relié selon le lien ci-dessous dit : 
https://docs.oracle.com/cd/E16764_01/core.1111/e10113/chapter_ssl_messages.htm

SSL-28861: SSL connection would block

Cause: This error is informational. It should never be communicated to the user.

Action: Enable tracing and retry the connection to determine the exact cause of the error. Contact Oracle customer support if needed.Level: 00001
Type: ERROR
Impact: Other

Dans ce cas, et avec l'information obtenue, je vais soir sur le site de support Oracle j'ai trouvé une note qui parle d'un problème similaire mais avec le client 10g, lequel supposément est corrigé avec le client 11g (Note : 1298611.1)

Pour essayer de voir si c'est le même cas, et afin de tester la recommandation d'Oracle malgré que ma version est 11g, je suis allé modifier le tnsnames du client en ajoutant le paramètre SEND_BUF_SIZE, afin d'avoir quelque chose comme ça: 

MYBD.WORLD=(DESCRIPTION =(SEND_BUF_SIZE=2557500)(ADDRESS = (PROTOCOL = TCPS)(HOST = myserver.domain )(PORT = 1822))(ADDRESS = (PROTOCOL = TCP)(HOST = myserver.domain)(PORT = 1821))(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = mybd.domain)(SECURITY= (SSL_SERVER_CERT_DN="CN=XXXXXX,OU=YYYYYY,O=ZZZ,L=ZZZZ,ST=ZZZ,C=CA"))))

Sur le serveur de base de données j'ai ajouté aussi une modification additionnelle sur le listener sécurisé qui dessert ladite base de données, dans ce cas-là, j'ai ajouté le paramètre RECV_BUF_SIZE

L_MYBD_SSL =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL=IPC)(KEY=EXTPROC1822))
      (ADDRESS = (PROTOCOL=TCPS)(HOST=myserver.domain)(PORT=1822))
      (RECV_BUF_SIZE=2557500))
    )
  )

C'est important de repartir le listener, pas juste un RELOAD, mais vraiment un STOP/START.

En faisant une autre fois les test, le problème semble corrigé. Le dépôt des BLOB's semble se faire sans problème cette fois à travers d'une connexion sécurisée.

Il faut remarquer que les valeurs utilisées dépendront bien sûr de vos configurations et comme vous savez, Oracle même ne donne pas une recommandation sur les valeurs. Donc, il faudrait calculer la bonne valeur afin de ne pas impacter le trafic sur le réseau non plus.

Drop database avec RMAN

Il y a quelques jours on m'avait demandé de supprimer une bd Oracle et j'ai bien profité pour créer un petit document que pourrait être utile à tous.

echo $ORACLE_SID
MYDB

srvctl remove database -d MYDB


rman target / catalog  user/apssword@BDCATALOG   ou rman target /
Recovery Manager: Release 12.1.0.2.0 - Production on Thu Aug 9 14:46:36 2018
Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
connected to target database: MYDB (DBID=2774697611)
connected to recovery catalog database


RMAN> REPORT SCHEMA ;
Report of database schema for database with db_unique_name MMYDB

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    1530     SYSTEM               YES     +DATINXRWMYDB/MMYDB/datafile/system.265.870780837
2    1490     SYSAUX               NO      +DATINXRWMYDB/MMYDB/datafile/sysaux.266.870780837
3    695      UNDOTBS1             YES     +DATINXRWMYDB/MMYDB/datafile/undotbs1.261.870780837
4    5        USERS                NO      +DATINXRWMYDB/MMYDB/datafile/users.259.870780839
5    5        TBS_RO_TEST01        NO      +DATINXROMYDB/MMYDB/datafile/tbs_ro_test01.265.870780839
6    10       TBS_PDF_01           NO      +DATINXROMYDB/MMYDB/datafile/tbs_pdf_01.dbf
7    200      GGS_DATA             NO      +DATINXRWMYDB/MMYDB/datafile/ggs_data.267.870780837

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    100      TEMP                 100         +TEMPMYDB/MMYDB/tempfile/temp.256.870780879
2    500      TEMP_NEW             32767       +TEMPMYDB/MMYDB/TEMPFILE/temp_new.257.881479571


RMAN> SHUTDOWN IMMEDIATE ;
database closed
database dismounted
Oracle instance shut down

RMAN> STARTUP MOUNT ;
connected to target database (not started)
Oracle instance started
database mounted

Total System Global Area    5368709120 bytes

Fixed Size                     5284640 bytes
Variable Size               1895832800 bytes
Database Buffers            3456106496 bytes
Redo Buffers                  11485184 bytes


RMAN> SQL 'ALTER SYSTEM ENABLE RESTRICTED SESSION';

sql statement: ALTER SYSTEM ENABLE RESTRICTED SESSION

Si on veut tout supprimer et ne pas laisser de traces des sauvegardes prises pour cette base de données on doit ajouter le INCLUDING BACKUPS.

RMAN> DROP DATABASE INCLUDING BACKUPS;

database name is "MYDB" and DBID is 2774697611

Do you really want to drop all backups and the database (enter YES or NO)? YES

allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=69 device type=DISK

List of Backup Pieces
BP Key  BS Key  Pc# Cp# Status      Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
1371427 1371426 1   1   AVAILABLE   DISK        /bkpdskrman/MYDB/01pue54s_1_1
1371445 1371439 1   1   AVAILABLE   DISK        /bkpdskrman/MYDB/02pue54v_1_1
1371446 1371440 1   1   AVAILABLE   DISK        /bkpdskrman/MYDB/03pue55o_1_1
1371464 1371461 1   1   AVAILABLE   DISK        /bkpdskrman/MYDB/04pue55s_1_1
1371474 1371472 1   1   AVAILABLE   DISK        /bkpdskrman/MYDB/05pue55v_1_1
deleted backup piece
backup piece handle=/bkpdskrman/MYDB/01pue54s_1_1 RECID=1 STAMP=870782108
deleted backup piece
backup piece handle=/bkpdskrman/MYDB/02pue54v_1_1 RECID=2 STAMP=870782111
deleted backup piece
backup piece handle=/bkpdskrman/MYDB/03pue55o_1_1 RECID=3 STAMP=870782137
deleted backup piece
backup piece handle=/bkpdskrman/MYDB/04pue55s_1_1 RECID=4 STAMP=870782140
deleted backup piece
backup piece handle=/bkpdskrman/MYDB/05pue55v_1_1 RECID=5 STAMP=870782144
Deleted 5 objects


released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=69 device type=DISK
specification does not match any datafile copy in the repository
specification does not match any control file copy in the repository
specification does not match any control file copy in the repository
List of Archived Log Copies for database with db_unique_name MMYDB
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - ---------
1371361 1    1       A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_1.312.870781535

1371362 1    2       A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_2.311.870781733

1371416 1    3       A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_3.310.870782095

1371421 1    4       A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_4.309.870782107

1371559 1    5       A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_5.321.870793853

1371438 1    5       A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_5.308.870782139

1371602 1    67      A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_67.320.870793939

1371603 1    68      A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_68.319.870793941

1371604 1    69      A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_69.318.870793941

deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_1.312.870781535 RECID=1 STAMP=870781535
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_2.311.870781733 RECID=2 STAMP=870781733
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_3.310.870782095 RECID=3 STAMP=870782094
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_4.309.870782107 RECID=4 STAMP=870782106
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_5.321.870793853 RECID=9 STAMP=870793852
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_5.308.870782139 RECID=5 STAMP=870782139
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_67.320.870793939 RECID=9 STAMP=870793940
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_68.319.870793941 RECID=10 STAMP=870793940
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_69.318.870793941 RECID=11 STAMP=870793941
Deleted 9 objects


database name is "MYDB" and DBID is 2774697611
database dropped

database name is "MYDB" and DBID is 2774697611
database unregistered from the recovery catalog

Bien sûr, il reste à faire le ménage dans les fichiers *.ora et selon le cas les policies de backup qu'auraient pu être reliés à cette base de données.