- Amleto
Qualcuno potrebbe pensare che scomodare addirittura Shakespeare per essere o meno un DBA sia un po eccessivo. Eccentirco forse, ma eccessivo no. Vediamo il perché.
NON essere un DBA è facile. Conosco qualcuno che si spaccia come tale, ma è ben lontano dall'esserlo. Piuttosto, essere un DBA, ha a che fare con il carattere. Ma a questo ci arriveremo.
I DBA, esistono a diversi livelli:
- Chi si occupa di Installazione, Configurazione e Monitoring dell'RDBMS
- Chi si occupa di Backup & Recovery (quì intendo anche Replicazione, Standby DB, etc)
- Chi si occupa di HA (RAC ad esempio)
- Chi si occupa di Performance and Tuning
- Chi supporta lo sviluppo (DBA Applicativo)
Ovviamente esistono anche altri livelli di esistenza, ma mi premeva far capire la complessità dell'universo DBA.
A tutto questo va aggiunto che un DBA deve conoscere:
- il Sistema Operativo, per affrontare problematiche si installazione, performance, tuning, backup
- SQL & PL/SQL, per poter fare interrogazioni mirate sul db sia per il tuining che per il monitoring. Senza tener conto del supporto che deve fornire in qui casi in cui il codice è scritto male
- linguaggi di scripting come bash, perl e tcl/tk, per il monitoring ed il reporting
- linguaggi di programmazione come C/C++ e Java, per affrontare problematiche di installazione, di configurazione, supporto allo sviluppo
non è detto che debba conoscere tutto e bene, ma il "conoscere" sicuramente aiuta.
Cosa fondamentale poi, è che il DBA deve saper ascoltare. Deve saper interpretare le esigenze degli utilizzatori del DB. Deve saper capire quali sono i limiti degli utenti e fornire ove necessario valide alternative. E' per questo, ad esempio, che risulta fondamentale la conoscenza dell'SQL e del PL/SQL.
Il DBA deve avere quindi del carattere per poter sapientemente argomentare pregi e difetti di una soluzione. Il DBA deve aver carattere nel saper riconoscere i propri limiti. Il DBA deve aver carattere nell'ammettere che altri ne sanno più di lui. E soprattutto il DBA deve aver carattere dimostrandosi umile.
Quindi: si può fare il DBA per necessità, lo si puòfare per prestigio o solo per lavoro. Ma soprattutto lo si può fare per passione. La differenza? La differenza è il risultato finale: chi lo fa per passione ha fame di informazioni ed è sempre alla ricerca di nuove sfide da superare.
Un DBA cerca di conoscere le strutture fisiche e logiche degli schemi dei database che gestisce e cerca di comprendere le applicazione che li utilizzano: indaga sui perché di eventuali problemi e fornisce, come detto, valide alternative. Badate bene che "valide alternative" non vuol dire creare un indice o lanciare le statistiche: ci sono già tools che fanno questo. Tom Kyte in un suo interessantissimo thread, spiega bene l'idea (riporto parte della discussione):
Tools apply a set of rule, heuristics (like the things I have in my head after doing it for 15 years)... I can look at a query, and a plan -- and with a KNOWLEDGE of the data (statistics to the software, even more knowledge to a human) -- I can generally "make the query better". Not always, but many times. That is the software does, it applies a series of rules to the queries and suggests (based on rules of thumb) enhancements to the schema or the query that would make it better. I've yet to see any software take a query though and say things like "well, if you remove that non-necessary outer join, use the analytic functions instead it'll run much faster". I see them say "add this index" sort of advice (very basic).
Ma non solo. Un DBA deve preoccuparsi anche e soprattutto della sicurezza dei dati. Spesso si tende a confondere tale termine. Credo che il modo giusto di vedere la cosa sia nel dire che "sicurezza" racchiude in se tre concetti distinti:
- Protezione
- Affidabilità
- Disponibilità
La sola mancaza di protezione implica l'assenza delle componenti di affidabilità e disponibilità. Se il dato non è protetto allora possiamo essere certi che prima o poi le modifiche fatte alla base dati andranno perse perché non esiste nesun criterio di garanzia sulle operazioni svolte.
Supponiamo ad esempio di avere uno schema, acceduto dall'applicazione per inviare sms (l'appicazione di produzione), dallo sviluppo per fare i test, dall'esercizio per la manutenzione e dal monitoring per controllare eventuali problemi. In questo caso la probabilità che un danno accidentale si verifichi risulta proporzionale alla grandezza della base dati e dal numero di utilizzatori della stessa.
Che dire: un gran casino.
Ho allora immaginato 3 leggi a cui un DBA deve attenersi. 3 leggi che devono governare la vita di un DB. Un po come le 3 leggi della robotica di Asimov (prima Shakespeare, adesso Asimov: chi mi ferma più):
- Prima Legge: Il DBA deve garantire la sicurezza dei dati. Deve cioè garantire che siano rispettati i vincoli di Protezione, Affidabilità e Disponibilità;
- Seconda Legge: Ogni utilizzatore del db deve modellare la propria base dati secondo le esigenze di performance della sua applicazione, purché queste non contrastino con la Prima Legge;
- Terza Legge: Il DBA deve fornire ogni tipo di supporto agli utilizzatori del database, deve raccogliere le loro esigenze e suggerire valide alternative purché venga rispettata la Seconda Legge;
Vorrei concludere citando Stéphane Faroult, autore di The Art of SQL, edito da O'Reilly. Il libro si rifà, come si evince dal titolo, all'Arte della Guerra di Sun Tzu (questa non ve l'aspettavate, vero?). Nell'introduzione del libro, Faroult scrive:
[...] I realized that the problem of teaching developers how to use database efficiently was similar to the problem of teaching officers how to conduct a war. You need knowledge, you need skills, and you need talent. Talent cannot be taught, but it can be nurtured.
Direi che questa frase calzi perfettamenteanche ai DBA, oltre che agli sviluppatori.
Nessun commento:
Posta un commento