Translation

The oldest posts, are written in Italian. If you are interested and you want read the post in English, please use Google Translator. You can find it on the right side. If the translation is wrong, please email me: I'll try to translate for you.

sabato, giugno 16, 2007

Le tre leggi

To be or not to be (a DBA), that is the question
- 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.


venerdì, giugno 01, 2007

Il Costo è Tempo?

Jonathan Lewis nel suo libro Cost-Based Oracle Fundamentals, nel Cap1 pagina 4 dice:

According to the CPU costing model:
Cost = (
#SRds * sreadtim +
#MRds * mreadtim +
#CPUCycles / cpuspeed
) / sreadtim

where

#SRDs - number of single block reads
#MRDs - number of multi block reads
#CPUCycles - number of CPU Cycles
sreadtim - single block read time
mreadtim - multi block read time
cpuspeed - CPU cycles per second

Translated, this says the following:

The cost is the time spent on single-block reads, plus the time spent on multiblock reads, plus the CPU time required, all divided by the time it takes to do a single-block read. Which means the cost is the total predicted execution time for the statement, expressed in units of the single-block read time.

L’affermazione che il “costo è il tempo” viene ribadito anche sul suo sito, dove aggiunge note al suo libro. La sezione “Cost is time (30th Dec 2005)”, termina infatti con: “Cost is Time – but the units are a bit funny”.

In realtà, come poi Lewis stesso ammette, le cose sono un pò diverse da come sembrano. In un thread del suo Blog infatti, si corregge con la seguente affermazione:

[…] I should have said “resource consumption” rather than cost […]

Di fatto, non possiamo utilizzare il costo di uno statement per dire se è buono o meno. Il motivo di tale affermazione è il risultato di un thread sul sito di Kyte che devo dire essere estremamente interessante.

Il mio personale consiglio è ovviamente di leggerlo. Qui riporto la risposta che Wolfgang Breitling in quel thread da ad una domanda fatta da un lettore:

To those who cling to the illusion that the "cost" of an explained sql is in any way related to the performance, read Tom's lips: "It is not".
The cost is used during the parse to pick one plan among all the ones considered (the one with the lowest "cost"). Once it has served that purpose and a plan is chosen, it is meaningless. In particular, it can NOT be compared to the cost of a another explain. If everything is the same between the two explain, the resulting plans and their costs will be the same. If they are not, then something is different and you can not compare the results anymore.
In pre-Oracle9, the "cost" is roughly equal to the estimated number of logical reads (db blocks needed to find the answer). That estimate of the number of blocks to be visited can be different from reality for a number of reasons, only a few of which could be considered bugs. A lot of the reasons for wrong estimates are due to data distribution and dependencies. That is what Tom refers to a human knowledge about the data which goes far beyond what the optimizer can discern from the statistics. For a presentation I am giving at the Hotsos Performance Symposium (IOUG wasn't interested) I have prepared testcases where the same query on tables with virtually identical statistics returns vastly different numbers of rows to show that it is impossible for the optimizer to come up with accurate estimates and therefore the best plan in all cases.

Cost and execution time are NOT related. There are plenty of examples that prove that they are not. The comparison of costs can only be made by the optimizer while it is parsing a sql and is evaluating different access paths. Once an access path is chosen it is invalid to compare its cost number to that of a different plan and draw any conclusion from it.
When parsing a sql the optimizer, in addition to using the gathered statistics - table as well as system in 9i - the optimizer has to make many assumptions about the data (uniform distribution for example in the absence of histogram data) and if the reality differs from the assumption the plan that came out with the lowest cost based on the assumptions can very well be far inferior to a plan that has a higher cost number (based on the assumptions) but is better suited to the reality and hence performs better. It is a rather far stretch to call the inability of the optimizer to accurately estimate certain characteristics of the data in the database, given limited information, a bug.