1. Download patches

2. backup precheck
   cd precheck
   ps -ef |grep pmon > current_instance.txt
   ps -ef |grep tns > current_tns.txt
   cat /etc/oratab > current_oratab.txt
   $ORACLE_HOME/OPatch/opatch lsinventory > before_current_lsinventory.txt

3. Check conflicts
   export PATH=$ORACLE_HOME/OPatch:$PATH
   opatch version
   unzip <patch.zip> && cd <path folder>
   opatch prereq CheckConflictAgainstOHWithDetail -ph ./

4. Stop oracle database and listeners

5. Check
   ps -ef|grep pmon
   ps -ef|grep tns
   ps -ef|grep exp
   ps -ef|grep rman

6. Apply patch
   opatch apply

7. Check
   opatch lsinventory > after_current_lsinventory.txt

8. Start only oracle database (not the listener)

9. Patch data
   datapatch -verbose

10. Check
    sqlplus / as sysdba
    SET LINESIZE 400
    COLUMN action_time FORMAT A20
    COLUMN action FORMAT A10
    COLUMN status FORMAT A10
    COLUMN description FORMAT A40
    COLUMN version FORMAT A10
    COLUMN bundle_series FORMAT A10

SELECT TO_CHAR(action_time, 'DD-MON-YYYY HH24:MI:SS') AS action_time,action,status,description,patch_id FROM sys.dba_registry_sqlpatch ORDER by action_time;

10. Check stop and start
    sqlplus / as sysdba
    shutdown immediate
    startup
    select name,open_mode from v$database;

11. Start the listener

0 - My Oracle Support patch 6880880 (OPatch) : https://updates.oracle.com/download/6880880.html
1 - Download the Patch from oracle support
2 - Copy patches to folder where oracle dba user has access
3 - For 6880880, zip old OPatch folder in $ORACLE_HOME
4 - Shutdown oracle database server and listener
5 - For other patch, go to $ORACLE_HOME and run command : ./opatch apply <path where the patch is>/patch.zip
6 - Startup oracle database server and listener
7 - ./datapatch -verbose
8 - In sqlplus (/ as sysdba) run : @?/rdbms/admin/utlrp.sql
9 - In sqlplus, check remaining INVALID objects : select owner, count(*) count from all_objects where status = ‘INVALID’ group by owner;

lsof | egrep "deleted|COMMAND"
-> note PID and FD number
file /proc/<PID>/fd/<FD number>
-> "broken symbolic link to ..."
echo > /proc/<PID>/fd/<FD number>

If datafiles of an INDEX tablespace, do not forget to check integrity :
select 'alter index "||index_name||' validate structure;' from dba_indexes where tablespace_name='PSINDEX';

[admcsav@frsu0462 ~]$ cat /etc/sysctl.d/97-oracle-hugepages.conf
vm.nr_hugepages=10310

[admcsav@frsu0462 ~]$ cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto spectre_v2=retpoline rd.lvm.lv=sysvg/root rd.lvm.lv=sysvg/swap rd.lvm.lv=sysvg/usr rhgb quiet numa=off transparent_hugepage=never"
GRUB_DISABLE_RECOVERY="true"

Pour la partie : « vm.nr_hugepages=10310 »
Le nombre est déterminé par le script dispo ici :
https://oracle-base.com/articles/linux/configuring-huge-pages-for-oracle-on-linux-64
(attention, le DBA indique de ne SURTOUT pas utiliser grubby comme indiqué dans cette doc)

Si datapump en erreur => CTRL-C

stop_job=immediate # peut être long, à tester sans le "immediate"

Faire les alter nécessaires.

Pour reprendre, vérifier les jobs datapump :
SELECT owner_name, job_name, operation, job_mode, state FROM dba_datapump_jobs;

Puis lancer le datapump :

impdp attach=SYS_IMPORT_FULL_01 # job_name

Dans datapump, si job_mode est "NOT RUNNING" :
start_job # ajouter =SKIP_CURRENT si c'est vraiment nécessaire.

Puis, pour faire l'équivalent d'un "fg" :
continue_client

$ ./rda.pl -T ora600:/u01/app/oracle/product/10.2.0/db_1/bdump/racdb1_pz99_8329.trc

Shrink TEMP Tablespace using alter tablespace command
SQL> ALTER TABLESPACE temp SHRINK SPACE KEEP 50M;.

Shrink TEMPFILE using alter tablespace command
SQL> ALTER TABLESPACE temp SHRINK TEMPFILE '/u01/app/oracle/oradata/TEST11G/temp01.dbf' KEEP 40M;

Shrink TEMP Tablespace to the smallest possible size:
SQL> ALTER TABLESPACE temp SHRINK SPACE;

SELECT pid FROM v$process
WHERE addr =
(
SELECT paddr FROM v$bgprocess
WHERE name = 'SMON'
);

ORADEBUG WAKEUP 6

run {
SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore';
RESTORE ARCHIVELOG FROM SEQUENCE 128458 UNTIL SEQUENCE 128510;
}

Les autotask(s) das Oracle !

===> No Archivelog mode:-
a) Online redolog file in INACTIVE and UNUSED state:-
This would not require crash recovery. Clear the logfile group and recreate the group manually by deleting the log file.
Commands:-
SQL> ALTER DATABASE CLEAR LOGFILE GROUP ;
SQL>ALTER DATABASE DROP LOGFILE GROUP ;
Delete the redolog file from the physical location.
SQL>ALTER DATABASE ADD LOGFILE GROUP ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 10M;
b) Online redolog file in ACTIVE state:-
This would require crash recovery. Issue a checkpoint.
Command:-
SQL>ALTER SYSTEM CHECKPOINT;
If the check point failed, then please do a complete recovery of the database from the last full backup. The steps to perform complete recovery are explained in the complete recovery section.

c) Online redolog file in CURRENT state:-
The LGWR will be terminated in this case and you have to perform complete recovery from cold backup.

===> Archivelog mode:-
a) Online redolog file in UNUSED state:-
The steps would be same as that of no archivelog mode.
b) Online redolog file in INACTIVE state:-
Check your redolog file is archive or not.
Command:-
SQL> set linesize 160
SQL> select group#,thread#,sequence#,members,status,archived from v$log;

Yes:-follow the same step as noarchive log mode.
No:- Issue the below command.
SQL>ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP ;
After this command there would be a gap in the archive log. So do complete recovery from backup.
c) Online redolog file in ACTIVE state:-
Perform a check point and if it fails then perform a complete recovery.
Command:-
SQL>ALTER SYSTEM CHECKPOINT;
d) Online redolog file in CURRENT state:-
The LGWR will be terminated in this case. We would have to perform incomplete recovery.

Steps for complete recovery:-

1. Using RMAN
2. Using multiplex copy of redolog file

a) Using RMAN:-
Connect to the target database and perform a recovery.
Commands:-
D:>rman target sys/@
RMAN> RESTORE DATABASE;
RMAN>RECOVER DATABASE;
RMAN>ALTER DATABASE OPEN;

b) Using Backup of redolog file:-
Apply the multiplex copy of redolog file and start the database.
SQL> alter database open;
Steps for Incomplete recovery:-

1. First find out the first change for the redolog file. This would be the SCN number.
   Command:-
   SQL> set linesize 160
   SQL> select group#,thread#,sequence#,members,status,to_char(first_change#) first_change,to_char(first_time,'YYYYMMDD HH:MI:SS') first_time from v$log;
   FIRST_CHANGE

   123456

2. Connect to RMAN and perform the incomplete recovery until SCN number -1;
   Command:-
   C:>rman target sys
   RMAN> RESTORE DATABASE UNTIL SCN ;
   RMAN> restore database until scn 123455;
   RMAN> recover database until scn 123455;
   RMAN> alter database open resetlogs;

Les commandes de “Recovery”

Vous pouvez utiliser différentes commandes « Recovery » selon la nature du crash qui va se présenter, je vais essayer de vous expliquer cela en restant le plus clair possible.Attention toutes ces commandes suppose que vous êtes en mode Archivelog est que vous avez vos fichiers d'archive log correspondant.

La commande : RECOVER DATABASE

Quand l'utiliser ? vous avez des fichiers de données qui vienent d'être corrompus/detruis et heureusement vous avez votre backup de la veille.Votre client ayant travailler toute la journée ne veux rien perdre et donc votre but maitenant est de restaurer votre anciens backup et de rejouer les archived log.

Methodologie :
a) Cette commande doit être utilisé seulement avec le « control file » courant ! En aucun cas vous de devez restaurer vos anciens "control file".
b) restaurer votre backup (sans les control files et les redo logs).
c) la base de donnée doit être monté (mount) mais pas ouverte.
d) le control file va comparer les en-têtes (header) des fichiers de donnée que vous allez restaurer et va mettre à jour les tablespaces qui ne le sont pas par le biais des archived log (en espérant que vous les avez toujours quelques parts !) et des currents online redo logs.
e) A la fin du « recover » vous pouvez ouvrir votre database avec la commande suivante : ALTER DATABASE OPEN

La commande : RECOVER DATAFILE ‘filename’

Quand l'utiliser ? vous venez de perdre un datafile, votre base donnée est “up”.

Methodologie :
a) le tablespace qui contient ces datafiles doit être place en mode offline : ALTER TABLESPACE ‘tablespace_name’ OFFLINE ;
b) restaurer votre fichier à l'aide de votre backup.
c) lancer ensuite la commande : RECOVER DATAFILE ‘filename’
d) Une fois que le « media recovery » terminé vous pouvez replacer votre tablespace en mode ONLINE.

La commande : RECOVER TABLESPACE ‘tsname’

Quand l'utiliser ? vous venez de perdre un ou plusieurs datafiles se référant à votre Tablespace.

Methodologie :
a) Le tablspace doit être place en mode offline et la database doit être ouverte : ALTER TABLESPACE ‘tablespace_name’ OFFLINE ;
b) restaurer votre ou vos fichiers de données se referant à votre Tablespace à l'aide de votre backup.
c) Lancer ensuite la commande : RECOVER TABLESPACE 'tsname'
d) Une fois que le « media recovery » terminé vous pouvez replacer votre tablespace en mode ONLINE.

Warning : Cette commande ne peux pas être utilisé avec le tablespace system ou un tablespace qui a des rollback segment ayant un statut « in use ».Si vous êtes confronté à ce genre de pb vous pouvez restaurer avec la commande standard « RECOVER DATABASE »

La commande : RECOVER DATABASE UNTIL CANCEL

Quand l'utiliser ? Cette méthode est utilisée lors de la restauration de base avec perte de fichiers journaux, qu'ils soient 'en ligne'
ou archivés. La commande doit être tapée avant d'atteindre les transactions concernant le fichier perdu ou endommagé.
Methodologie :
a) Il s’agit en faite d’une restauration partielle.
b) restaurer votre dernier backup
c) lancer ensuite la commande : RECOVER DATABASE UNTIL CANCEL
d) la restauration se passe en interactif et vous suggère les fichiers d’archive log qui vont être rejoués.
e) la restauration est terminé lorsque vous spécifiez « CANCEL » a la place du « filename ».

La commande : RECOVER DATABASE UNTIL TIME <date&time>
Quand l'utiliser ? vous avez eu un pb (physique ou logique) sur votre database dans la journée et vous voulez restaurer les transations avant le point de rupture car vous en connaissais son heure.Oracle terminera automatiquement la restauration lorsqu'il aura atteint l'heure spécifiée. Toutes les transactions commencées avant cette heure mais validées plus tard sont annulées.

Methodologie :
a) Il s’agit en faite d’une restauration partielle comme le UNTIL CANCEL et la granualitée temporelle dépend des archives log.
b) restaurer votre dernier backup
c) lancer ensuite la commande : RECOVER DATABASE UNTIL TIME <date&time>

le format <date&time> est YYYY-MM-DD:hh:mm:ss ou YYY:MM:DD est l'année, mois et jours et hh est l'heure, mm minutes, and ss seconds.

La commande : RECOVER DATABASE UNTIL <TIME/CANCEL> USING BACKUP CONTROLFILE

Quand l'utiliser ? vous avez perdu vos controlfile et vous les avez simplement sauvé sur votre dernier backup.

Methodologie :
a) Il s’agit en faite d’une restauration similair au RECOVER DATABASE.
b) restaurer votre dernier backup.
c) lancer ensuite la commande : RECOVER DATABASE { UNTIL TIME <date&time> / UNTIL CANCEL} USING BACKUP CONTROLFILE

Réinitialisation des fichiers journaux

Il est possible de réinitialiser les fichiers journaux après une restauration complète ou non de la base. La commande ALTER DATABASE RESETLOGS effectue les actions suivantes :

Annule toutes les transactions des fichiers journaux qui n'ont pas été appliquées durant la restauration.
Réinitialise le numéro de séquence du fichier de contrôle à 1.
Vide le fichier journal courant.
Crée le fichier journal courant s'il n'existe pas.
Réinitialise le numéro de séquence des fichiers journaux à 1 dans tous les en-têtes des fichiers.

NORESETLOGS ou RESETLOGS ?

Quand doit-on utiliser la commande ALTER DATABASE OPEN NORESETLOGS ou ALTER DATABASE OPEN RESETLOGS ?

Si une sauvegarde du fichier de contrôle a été utilisée, réinitialiser le numéro de fichier journal.
Dans le cas d'une restauration incomplète (vérifier le message dans le fichier d'ALERT), réinitialiser le numéro de fichier journal.
Dans le cas d'une restauration complète sans utilisation de sauvegarde de fichier de contrôle, ne pas réinitialiser le numéro de fichier journal. Si les numéros de séquence doivent être réinitialisés, fermer la base et effectuer une sauvegarde OS.
Après l’utilisation de RESETLOGS, il est impératif de faire une sauvegarde totale de la base de données

Si chaque commande marche :

alter system archive log current;

shutdown;

Sinon :

shutdown abort

mount

Sinon, reste rman :

list failure;

advise failure;

repair failure;

Reste ensuite à ouvrir la base en resetlogs.

ORA-00600

Pour forcer l'ouverture de la base alors qu'il manque des choses :

SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile;
System altered.

SQL> alter system set undo_management='MANUAL' scope=spfile;
System altered.

SQL> shutdown abort;
ORACLE instance shut down.
SQL> startup;

===> Faire le shutdown et startup plusieurs fois jusqu'au succès (il faudra éventuellement se reconnecter avec un conn / as sysdba)