Oracle database in backup mode

Durante la mia consulenza su database Oracle, mi è capitato di diagnosticare database in backup mode; ovvia conseguenza di un backup terminato in modo non corretto...
Se ci troviamo a gestire una versione uguale/superiore alla 10g, un semplice

SQL>  ALTER DATABASE END BACKUP;

risolverà il problema (vedi con select * from v$backup), ma per le versioni precedenti, il lavoro diventa più operoso: dovremo tablespace per tablespace eseguire un END BACKUP.

Vediamo di facilitare il compito con uno script che chiamo end_backup.sql.

rem -----------------------------------------------------------------------
rem Filename:   end_backup.sql
rem Purpose:    This script will create a file called end_backup_script.sql
rem                - run it to take all tablespaces out of backup mode.
rem -----------------------------------------------------------------------

column cmd format a80 heading "Text"
set feedback off
set heading  off
set pagesize 0

spool end_backup_script.sql

select   'alter tablespace '||a.tablespace_name||' end backup;' cmd
from     sys.dba_data_files a, sys.v_$backup b
where    b.status = 'ACTIVE'
and      b.file#  = a.file_id
group by a.tablespace_name
/

spool off

set feedback on
set heading  on
set pagesize 24
set termout  on

start end_backup_script.sql


Salviamo lo script in un file, diciamo $ORACLE_HOME/end_backup.sql ed eseguiamo l'accesso nel database con sqlplus utente sys as sysdba.

Una volta entrati nella shell sql lanciamo

SQL> @?/end_backup.sql

Verifichiamo lo stato del database con

SQL> SELECT * FROM V$BACKUP;

NOT ACTIVE = non in backup mode.

Debian GNU/Hurd, la rivincita del micro?

Il 23 Maggio è stata rilasciata la distribuzione Debian con kernel GNU/Hurd: un travaglio!
Ormai da più di vent'anni la comunità della Free Software Foundation stava lavorando a questo kernel, che nelle intenzioni di Richard Stallman doveva essere il nucleo pulsante di GNU.

L'architettura del kernel negli anni è stata implementata in diverse versioni; inizialmente basata su kernel Mach, poi L4 ed infine Coyotos (successore di EROS).

Dalle note di rilascio, si evince la scelta iniziale: il kernel Mach; ma cos'è questo GNU/Hurd e perché non è poi così significativo il suo rilascio?

Kernel Monolitico
Un sistema operativo dovrebbe, come prima funzionalità, essere affidabile e funzionare senza problemi, ma, sfortunatamente, i sistemi operativi di oggi disattendono queste prospettive (il riferimento è al mercato mainstream/enterprise).
Le maggiori problematiche, derivano in primis proprio dall'architettura monolitica dei più comuni sistemi oggi in produzione.
In un sistema monolitico (come il kernel Linux, seppur modulare), il sistema operativo è un unico blocco di codice eseguito in modalità privilegiata che implementa tutte le funzionalità tipiche di un sistema operativo.
Ergo, tutte queste funzioni in kernel-mode non garantiscono un isolamento al fault del codice, perciò ogni bug può potenzialmente compromettere l'intero sistema. Molti ricercatori hanno evidenziato come il 70-80% dei casi di panic del kernel, derivino dai driver eseguiti in kernel-mode.

Kernel Single-Server
Il Single-Server è un kernel ridotto che esegue un sistema monolitico in user-mode. Sfortunatamente, l'affidabilità del sistema non si discosta di molto da un sistema monolitico in quanto anche in questa architettura è presente un 'single point of failure'.
Esempi di kernel Single-Server sono considerati il Mach-UX e il L4Linux.
Per la cronaca, uno dei primi sistemi Single-Server fu il Mach-UX che eseguiva un BSD sopra ad un Mach 3 a microkernel, noto ai più per le sue basse performance: circa 50% più lento della versione normale del BSD.

Kernel Multiserver
L'architettura dominante nelle installazioni mission critical real time (RTOS) è data da sistemi Multiserver System a microkernel (QNX, LynxOS, per citarne un paio), dove un qualsivoglia software di terze parti è destinato a lavorare isolato in user-mode.
Un kernel di questo tipo non dovrebbe superare le 50000 linee di codice (per i monolitici siamo oltre i 7 milioni), cosa che rende il sistema agevolmente comprensibile e di facile manutenzione.
Come esempio, prendo in esame il microkernel di Minix 3 un sistema operativo UNIX-like in grado di perdurare al crash di componenti critici, come ad esempio un device driver.

Il kernel di Minix è costituito solo dal gestore IRQ, IPC e da uno scheduler più due kernel task: SYS e CLOCK. Tutto il resto (Networking, File system, Drivers, ecc.) gira al difuori del kernel in user-mode, incapsulato in uno spazio di indirizzi privato che viene protetto dall'hardware attraverso l'MMU. In questo modo, è garantita un'alta affidabilità del sistema.

I detrattori del microkernel hanno sempre sostenuto che questo modo di agire penalizzava fortemente le performance. Se ciò poteva essere vero negli anni '80, ad oggi è solo uno sproposito, basti pensare al utilizzo di QNX per alcuni apparati Cisco (IOS XR): ...possiamo credere che Cisco è certamente interessata alle performance!


Affidabilità dunque è il tema dominante e GNU/Hurd è un microkernel multiserver rilasciato sotto licenza GPL con l'aspirazione di scalzare il dominio del kernel Linux sul software GNU.

Il progetto però è in costante ritardo e si deve misurare con altri progetti simili e ben più blasonati, già consolidati nel mercato embedded. Rimane da conquistare il mercato mainstream ed enterprise. Omnia cum tempora...