Installer Oracle XE 18c sur Centos 8

travail sur ordinateur

Cette procédure d’installation se déroule avec l’utilisateur root. Elle a été déroulée sur une VM centos 8 minimaliste telle que distribuée par linuxvimages.com.

Elle permet d’installer Oracle XE sur une VM Centos 8, l’intérêt est essentiellement pédagogique. En effet Oracle XE est très limitée (12 Go de données utilisateur au maximum, 2Gb de mémoire, 2 Threads … et 3 PDB, mais on s’en cogne ça ne sert à rien sur des volumétries si faibles).

Malgré ces limitations les interpréteurs SQL et PL/SQL sont complets ce qui en fait un excellent outil de formation.

Installation des packages

dnf install -y epel-release
dnf install -y rlwrap wget libnsl

wget http://mirror.centos.org/centos/7/os/x86_64/Packages/compat-libstdc++-33-3.2.3-72.el7.x86_64.rpm
wget http://mirror.centos.org/centos/7/os/x86_64/Packages/compat-libcap1-1.10-7.el7.x86_64.rpm
dnf install -y compat-libcap1-1.10-7.el7.x86_64.rpm compat-libstdc++-33-3.2.3-72.el7.x86_64.rpm

curl -o oracle-database-preinstall-18c-1.0-1.el6.x86_64.rpm https://yum.oracle.com/repo/OracleLinux/OL6/latest/x86_64/getPackage/oracle-database-preinstall-18c-1.0-1.el6.x86_64.rpm
dnf -y localinstall oracle-database-preinstall-18c-1.0-1.el6.x86_64.rpm

curl -o oracle-database-preinstall-18c-1.0-1.el7.x86_64.rpm https://yum.oracle.com/repo/OracleLinux/OL7/latest/x86_64/getPackage/oracle-database-preinstall-18c-1.0-1.el7.x86_64.rpm
dnf -y localinstall oracle-database-preinstall-18c-1.0-1.el7.x86_64.rpm

wget https://download.oracle.com/otn-pub/otn_software/db-express/oracle-database-xe-18c-1.0-1.x86_64.rpm
dnf install -y oracle-database-xe-18c-1.0-1.x86_64.rpm

Personnalisation

Je souhaite que la base de données XE soit stockée sous l’arborescence /data.

mkdir /data
chown oracle:oinstall /data

Configuration de la création de XE

Le fichiern /etc/oratab doit être créé avant de lancer le création de a base.

touch /etc/oratab
chown oracle:oinstall /etc/oratab

cat <<_HERE > /etc/sysconfig/oracle-xe-18c.conf
#This is a configuration file to setup the Oracle Database.
#It is used when running '/etc/init.d/oracle-xe-18c configure'.

# LISTENER PORT used Database listener, Leave empty for automatic port assignment
LISTENER_PORT=1521

# EM_EXPRESS_PORT Oracle EM Express URL port
EM_EXPRESS_PORT=5500

# Character set of the database
CHARSET=AL32UTF8

# Database file directory
# If not specified, database files are stored under Oracle base/oradata
DBFILE_DEST=/data

# SKIP Validations, memory, space
SKIP_VALIDATIONS=false
_HERE

Création de la base de données

/etc/init.d/oracle-xe-18c configure

Normalistaion pour utilisation de oraenv

cd /opt/oracle/product/18c/dbhomeXE/bin
cp oraenv dbhome orabase /usr/bin

bash profile de l’utilisateur oracle

cat <<_HERE > ~oracle/.bash_profile

alias sqlplus='rlwrap sqlplus'
alias sys='sqlplus / as sysdba'

export ORACLE_SID=XE
export ORAENV_ASK=NO
. oraenv
_HERE

chown oracle:oinstall ~oracle/.bash_profile

Configuration du service oracle pour redémarrage après reboot

systemctl start oracle-xe-18c
systemctl enable oracle-xe-18c

Lister les paramètres cachés et ce qu’ils font

cachée

Les paramètres cachés sont ceux qu’on n’est pas censé toucher. Ceux qui sont là en cas d’extrème urgence pour contourner un bug le temps qu’Oracle ponde un « patch ». Ils sont là pour contourner les bugs, c’est du moins le message du support Oracle.

Ils servent aussi d’interrrupteur et de paramétrage des fonctionalités ( le nombre de secondes entre deux snapshots d’ASH, c’est un paramètre caché, l’utilisation de certaines fonctions de l’optimiseur ce sont aussi des paramètres cachés.) Afin de les trouver et de déterminer leur fonction, il est possible d’interroger la base de dpnnées ou plus exctement ses structures mémoire qui ont ces informations en stock.

set lines 155 pages 50000

SELECT
x.inst_id inst_id,
x.indx num,
x.ksppinm name,
decode(x.ksppity, 1, 'BOOLEAN',
2, 'STRING',
3, 'INTEGER',
4, 'PARAMETER FILE',
5, 'RESERVED',
6, 'BIG INTEGER', 'UNKNOWN') type,
y.ksppstvl value,
decode(y.ksppstdf, 'TRUE', 'DEFAULT VALUE',
'FALSE', 'INIT.ORA') isdefault,
decode(bitand(x.ksppiflg / 256, 1), 1, 'IS_SESS_MOD(TRUE)', 'FALSE') isses_modifiable,
decode(bitand(x.ksppiflg / 65536, 3), 1, 'MODSYS(NONDEFERED)',
2, 'MODSYS(DEFERED)',
3, 'MODSYS(*NONDEFERED*)', 'FALSE') issys_modifiable,
decode(bitand(y.ksppstvf, 7), 1, 'MODIFIED_BY(SESSION)',
4, 'MODIFIED_BY(SYSTEM)', 'FALSE') ismodified,
decode(bitand(y.ksppstvf, 2), 2, 'ORA_STARTUP_MOD(TRUE)', 'FALSE') isadjusted,
x.ksppdesc description,
y.ksppstcmnt update_comment,
x.ksppihash hash
FROM x$ksppi x, x$ksppcv y
WHERE x.inst_id = y.inst_id
and x.indx = y.indx
and x.ksppinm like '%&name%';

ou

set lines 155 pages 50000

col name for a40
col type for a15
col value for a30 wrap

SELECT
x.ksppinm name,
decode(x.ksppity, 1, 'BOOLEAN',
2, 'STRING',
3, 'INTEGER',
4, 'PARAMETER FILE',
5, 'RESERVED',
6, 'BIG INTEGER', 'UNKNOWN') type,
y.ksppstvl value,
decode(bitand(y.ksppstvf, 7), 1, 'MODIFIED_BY(SESSION)',
4, 'MODIFIED_BY(SYSTEM)', 'FALSE') ismodified,
decode(bitand(y.ksppstvf, 2), 2, 'ORA_STARTUP_MOD(TRUE)', 'FALSE') isadjusted,
x.ksppdesc description
FROM x$ksppi x, x$ksppcv y
WHERE x.inst_id = y.inst_id
and x.indx = y.indx
and x.ksppinm like '%&name%';

Ce qui pour la vraible name settée à « quarantine » en Oracle 19c donne :

NAME TYPE VALUE ISMODIFIED ISADJUSTED
DESCRIPTION
_quarantine_enabled BOOLEAN TRUE FALSE FALSE
quarantine: enable
_quarantine_max_objs INTEGER 10000 FALSE FALSE
quarantine: max number of objects
_quarantine_max_mem INTEGER 1 FALSE FALSE
quarantine: max amount of memory
_quarantine_per_hour INTEGER 60 FALSE FALSE
quarantine: limit per hour
_optimizer_quarantine_sql BOOLEAN TRUE FALSE FALSE
enable use of sql quarantine

Version du Cluster Ready Service

Support

Demandé par le support Oracle pour connaitre la version du Cluster Ready Service noeud par noeud, le passage des instructions crsctl query crs en masse peut être fastidieux. Voici donc une petite fonction bash pour obtenir les informations sous linux. Il faut bien sûr qu’elle soit lancée par l’utilisateur propriétaire de la grid-infrastructure et que la variable GI_HOME corresponde à son répertoire d’installation

function racCrsVersions {
for s in $(olsnodes)
do
echo ""
echo "===> $s"
echo ""
echo " - activeversion -f ==> $( ssh $s ${GI_HOME}/bin/crsctl query crs activeversion -f )"
echo " - softwareversion  ==> $( ssh $s ${GI_HOME}/bin/crsctl query crs softwareversion  )"
echo " - softwarepatch    ==> $( ssh $s ${GI_HOME}/bin/crsctl query crs softwarepatch    )"
echo " - releaseversion   ==> $( ssh $s ${GI_HOME}/bin/crsctl query crs releaseversion   )"
echo " - releasepatch     ==> $( ssh $s ${GI_HOME}/bin/crsctl query crs releasepatch     )"
done
}

Le résultat de la requête peut être le suivant :

===> racnode01

 - activeversion -f ==> Oracle Clusterware active version on the cluster is [19.0.0.0.0]. The cluster upgrade state is [UPGRADE FINAL]. The cluster active patch level is [724960844].
 - softwareversion  ==> Oracle Clusterware version on node [racnode01] is [19.0.0.0.0]
 - softwarepatch    ==> Oracle Clusterware patch level on node racnode01 is [724960844].
 - releaseversion   ==> Oracle High Availability Services release version on the local node is [19.0.0.0.0]
 - releasepatch     ==> Oracle Clusterware release patch level is [724960844] and the complete list of patches [29401763 29517242 29517247 29585399 ] have been applied on the local node. The release patch string is [19.3.0.0.0].

===> racnode02

 - activeversion -f ==> Oracle Clusterware active version on the cluster is [19.0.0.0.0]. The cluster upgrade state is [UPGRADE FINAL]. The cluster active patch level is [724960844].
 - softwareversion  ==> Oracle Clusterware version on node [racnode02] is [19.0.0.0.0]
 - softwarepatch    ==> Oracle Clusterware patch level on node racnode02 is [724960844].
 - releaseversion   ==> Oracle High Availability Services release version on the local node is [19.0.0.0.0]
 - releasepatch     ==> Oracle Clusterware release patch level is [724960844] and the complete list of patches [29401763 29517242 29517247 29585399 ] have been applied on the local node. The release patch string is [19.3.0.0.0].

===> racnode03

 - activeversion -f ==> Oracle Clusterware active version on the cluster is [19.0.0.0.0]. The cluster upgrade state is [UPGRADE FINAL]. The cluster active patch level is [724960844].
 - softwareversion  ==> Oracle Clusterware version on node [racnode03] is [19.0.0.0.0]
 - softwarepatch    ==> Oracle Clusterware patch level on node racnode03 is [724960844].
 - releaseversion   ==> Oracle High Availability Services release version on the local node is [19.0.0.0.0]
 - releasepatch     ==> Oracle Clusterware release patch level is [724960844] and the complete list of patches [29401763 29517242 29517247 29585399 ] have been applied on the local node. The release patch string is [19.3.0.0.0].

AWR en 11gR2, bogue lié au changement de valeur de control_management_pack_access

Dans le post précédent je me suis trouvé confronté au souci suivant: le passage du paramètre control_management_pack_access de NONE à DIAGNOSTIC+TUNING sur Linux ne déclenchait pas toutes les collectes de statistiques nécessaires au bon établissement d’un rapport AWR et ce malgré le caractère dynamique dudit paramètre.

Deux contournements m’ont été proposés par le support :

  1. Redémarrer la base (SIC!)
  2. Ou manuellement Alimenter les tables dont les données ne sont pas collectées à l’aide des scripts suivants :

(suite…)

AWR en 11gR2 me dit « No data exists for this section of the report »

Franchement quel vilain cet AWR… Non ? Me faire ça à moi, No data exists for this section of the report, n’ai je donc tant administré de bases que pour cette infamie ? Un peu de respect que diable !!!

Pourtant j’ai vérifié statistics_level est bien positionné à ‘TYPICAL’ et il y a des clichés dans dba_hist_snapshot

SQL&gt; select snap_id
  2       , to_char(end_interval_time,'YY/MM/DD HH24:MI:SS') EIT
  3  from dba_hist_snapshot
  4   where end_interval_time &gt; trunc(sysdate)
  5  order by 1
  6  /

(suite…)

Sauvegarder la config de putty

Putty

Putty est un client multiprotocole pour windows diponible sur le site putty.org. La sauvegarde de sa configuration n’est plus très facile depuis qu’il ne s’appuie plus sur un fichier de configuration mais sur la base de registre de Windows. Le script suivant permet la sauvegarde des la configuration putty dans un fichier reg

Le script

@ECHO OFF
regedit /s putty.reg
regedit /s puttyrnd.reg
start /w putty.exe
regedit /ea new.reg HKEY_CURRENT_USERSoftwareSimonTathamPuTTY
copy new.reg putty.reg
del new.reg
regedit /s puttydel.reg

Le script a été trouvé dans la doc PuTTY et utilise deux fichiers de paramètre puttyrnd.reg et puttydel.reg. leur utilisation est expliquée sur le site de la doc