Yuk, Yuk, Yukon!
a cura di Sabrina Cosolo (requisiti: conoscenza generica di SQL Server)

(Relazione informale sull'evento Yukon Overview del 22 settembre 2003, organizzato da UGISS (User Group Italiano SQL Server) presso la sede Microsoft di Segrate).

Premessa
Questa serie di pensieri quasi sconnessi non sono altro che il riporto dei miei appunti e dei miei ricordi, ogni errore od orrore è da imputarsi solo a me, non di certo ai relatori di UGISS che sono stati non solo esaurienti, ma anche pronti a punzecchiare il rappresentante ufficiale di Microsoft, Silvano Coriani, quando il pubblico faceva domande pertinenti o impertinenti su quello che veniva presentato.
Un plus va al collega di Gianluca Hotz, Franco Perduca, che, presentando i servizi Dts (Data transformation services, si è lanciato temerariamente nelle Demo sulla Beta 1, un po' più di Gianluca, ed è incocciato nel classico inchiodamento del sistema che comunque è riuscito a gestire in modo encomiabile.

Gli argomenti della presentazione di Yukon sono stati, nell'ordine:

Questa relazione verte per il 99% sulla sessione mattutina, in quanto i Dts e il loro uso per la costruzione di database via OLAP non sembrano al momento interessare la mia attività e molto di quanto mi è stato mostrato è ai miei occhi poco lontano dal cinese antico.

Ma veniamo al dunque, ecco quel che è stato presentato da Gianluca Hotz (MVP SQL Server) nella sessione mattutina, dedicata alla struttura e alle nuove funzionalità di Yukon:

Una rivoluzione
Prima affermazione: non si tratta semplicemente di una nuova release ma di una completa reingegnerizzazione e direi pure di una serie di rivoluzioni dietro le quinte; questo perché il nuovo file system di Windows 200?? (Longhorn), così come anche il nuovo Exchange si baseranno su Yukon.
Non è ufficiale, naturalmente, in quanto entrambi sono ancora a livello di alfa nella mente dei progettisti di Microsoft, però ci sono alcune implementazioni sui tipi di dati di Yukon che danno qualche suggerimento in merito.
Aggiungiamo che ci saranno più tecnologie, più infrastrutture a sostegno dei servizi forniti da Yukon e per parlarne ancora ci saranno molto presto alcuni appuntamenti. Un Workshop sui Reporting services che sarà organizzato da UGISS, la Windows Professional Conference organizzata da Microsoft e Mondatori Education e naturalmente la Professional Developer Conference a Los Angeles a fine ottobre.

Detto questo inizia la presentazione vera e propria e da cosa si inizia?

I Cluster
Yukon è disegnato per dare la massima "availability" dei dati, ovvero dati disponibili per 24 ore su 24 , 365 giorni all'anno; perciò si inizia da ciò che piace di più a MS, i Cluster (of course).
Yukon supporterà, grazie a Windows 2003, cluster a 4 nodi per la versione Enterprise e a 8 nodi per la versione Data Center.
Tutti i servizi di Yukon funzionano in cluster (con 2000 non era proprio così).

Ora vorrei che tra tutti i membri di VB-T&T alzino la mano coloro che hanno mai visto un Cluster. Io, nel mio piccolo, li considero come il meccanico che aggiusta le VolksWagen può considerare uno Space Shuttle. E' certo che sapere che esistono e possono essere utilizzati ci può tornare utile, ma dubito che nella realtà territoriale del Nord Est Italia in cui opero se ne presenterà mai l'esigenza. Un simile tipo di installazione potrebbe essere utilizzato da un Web provider; sicuramente il fatto che ci sia è cosa buona e giusta, ma non è pane per i comuni mortali, e neppure per i comuni DBA.

Dopo i Cluster, si passa a cose più terrene anche se comunque per applicazioni di tipo enterprise, ovvero quello che si chiama DBMirroring: una evoluzione di quello che in SQL Server 2000 era il Log Shipping. Dato che questo articolo è pubblicato anche per i non SQL Server Professional vi spiego di cosa si tratta:

Il Log Shipping
Poniamo di avere un Server SQL 2000 Enterprise in Produzione, dove vengono registrate tutte le operazioni compiute giornalmente da una azienda (Produzione intesa come produzione dati non come officina). In questo server avremo uno o più database che conterranno tutti i dati del gestionale aziendale. E' certo che, se si tratta di un server Enterprise, sicuramente avremo una macchina corazzata, perciò: un RAID, un sistema di Backup su cassetta ben strutturato etc.
Però, in caso di sfortuna nera (ovvero un fulmine colpisce direttamente il server che cessa di vivere), l'azienda avrebbe un sia pur minimo tempo di indisponibilità dei dati, ad esempio una giornata lavorativa, il che potrebbe significare una perdita non accettabile (pensate al costo di 100 persone ferme per una giornata lavorativa). Se l'azienda non ha comunque un budget tale da permettersi il cluster, può però, con una spesa non eccessiva, utilizzare il Log Shipping. Ovvero può avere una macchina di Backup, magari un po' più piccola del server di produzione, anche se comunque abbastanza corazzata, con un secondo SQL Server Enterprise installato. Su questa macchina verrà installata una copia di backup del database di produzione ed è possibile, mantenendo tale copia in stato di "Standby", ovvero accessibile in sola lettura, attivare un meccanismo di Log Shipping temporizzato; ovvero il server di produzione fa un Backup del log delle transazioni del database di produzione e lo spedisce al server in StandBy che ne fa un restore; a questo punto, il server in StandBy ha una copia aggiornata dei dati del server di produzione in base al nostro criterio di temporizzazione, un giorno, un'ora, cinque minuti etc.
Qualcuno potrebbe dire: "Bello, ma ho un server che non SERVER a niente, è una bella spesa nonostante tutto".
Vero, è una bella spesa, ma è anche vero che lo Standby server non è proprio inutile. Infatti sul DB sul server Standby si può accedere ai dati in lettura, e questo permette di utilizzare il DB su Standby per produrre tutte le statistiche, i report, le interrogazioni che sono necessarie all'ufficio commerciale, a chi si occupa di pianificazione della produzione, al CAPO etc. senza appesantire con query mostruose il Server di Produzione che è già indaffarato a inserire e modificare i dati provenienti dagli operatori dell'amministrazione, reparto acquisti, reparto vendite, spedizioni, magazzino e produzione.
In caso di disastro al server primario, il server standby può essere tramutato in server di produzione nel giro di pochi minuti, rimane solo il problema che i client devono essere reindirizzati al nuovo server. Ma se il System administrator è furbo come il mio collega, che ha provveduto a fare in modo che SQL Server in azienda non sia visto come \\nomeserver\nomeinstanza bensì come sql.nomedominio.local, credo che il tutto si limiti a qualche minuto di pausa prima di far ripartire la produzione.

Il DBMirroring
Ora, posto che tutto questo era fattibile con SQL Server 2000, in Yukon è stato migliorato ulteriormente con quello che viene definito DBMirroring, ovvero: predisponendo come per il Log Shipping i due server Produzione e Standby, al server Standby non verrà più spedito il log delle transazioni in modo temporizzato, ma verranno spedite direttamente le transazioni, questo permetterà al server Standby di avere i dati praticamente in tempo reale.
In questo modo, in caso di Failover (disastro totale in produzione), il tempo di attivazione del server Standby è praticamente zero: infatti, una volta passato il server da Standby a On-line, i client possono essere programmati per cercare automaticamente il server Standby quando il primario non fosse disponibile (il che significa ancora meno lavoro per il sysadmin...). Inoltre i dati persi non sarebbero tutti quelli inseriti dopo l'ultimo log shipping, ma solo le transazioni in piedi al momento del disastro.

I pregi primari di questo mirroring: niente Storage condivisi, niente hardware particolare (cluster), l'unico requisito da raccomandare è solo, possibilmente, una buona connessione di rete fra i due server che (ovviamente) si troveranno in due luoghi diversi.
L'impatto sul carico di lavoro del server di produzione per l'invio delle transazioni dipende infatti dal numero di transazioni e chiaramente dalla velocità di connessione. In caso di server con transazioni in notevole quantità sarebbe auspicabile l'uso di una fibra ottica.

Lock Snapshot
Dopo la parte di data availability ci si è addentrati nelle dinamiche di Yukon parlando di transazioni e più specificamente di 'isolamento' delle transazioni. Qui ammetto di aver smarrito un passaggio: se non è chiaro ciò che scrivo è colpa mia!

Le transazioni all'interno di SQL Server 2000 supportano 4 tipi di isolamento che sono Serializable, Repeat Read, Read Committed, Read Uncommitted.
Su Yukon è stato utilizzato il livello di isolamento Snapshot, ovvero la lettura di un dato in fase di aggiornamento viene effettuata sull'ultimo dato valido, cioè sul valore che aveva prima della transazione attualmente in corso. Sempre per migliorare l'availability. Non ho ben capito se questo tipo di comportamento è opzionale oppure è lo standard.
Anche in questo caso della gestione dei lock, come in quello dei cluster, sono comunque davvero poche le applicazioni in cui ci sia necessità di un controllo maniacale della consistenza dei dati, (ad esempio le transazioni di borsa o quelle bancarie, ma accetto suggerimenti da chi ne ha affrontati davvero.)

Manutenzione degli indici
Proseguendo con le novità, anche se questo impone una maggiore quantità di spazio su disco occupato durante le operazioni, è stata introdotta in Yukon la possibilità di fare manutenzione degli indici senza bloccare il lavoro sulle tabelle, come è ora necessario; tutti gli indici possono perciò essere ricostruiti senza che il DB debba essere bloccato, un altro dei passi verso la massima "availability". E' comunque chiaro che durante la ricostruzione degli indici il DB rallenterà un pochino.
Il Backup Full del Database non blocca il Backup del Log, ovvero: mentre viene effettuato un Backup Full, può essere contemporaneamente effettuato il Backup del Log delle transazioni. Ovviamente non si possono invece lanciare due backup full contemporaneamente (meglio specificarlo perché gli utenti hanno sempre strane idee...).
Nei Backup adesso vengono salvati anche i Full Text catalog e inoltre vengono inclusi i dati di tipo Filestream.

I FileStream
Essendosi scoperto con i Filestream, Gianluca Hotz ha dovuto sbottonarsi un po' al riguardo, anche se è rimasto molto sul vago; infatti questo nuovo tipo di dati (cui ho accennato all'inizio) non è ancora ben definito. A quanto pare, il tipo di dato filestream sarà un riferimento a oggetto su file system, apparirà (presumo) come semplice riferimento a oggetto (non come copia dello stesso), ma al momento del Backup salverà anche l'oggetto a cui fa riferimento.
Questo è ciò che è stato accennato, prendiamo le cose con le pinze proprio perché non c'è nulla di ufficiale in merito.

Certezza dei dati
Passiamo a qualcosa che mi è sembrato un po' nebuloso, ovvero la gestione della certezza dei dati memorizzati:
per la sicurezza dei dati scritti, oltre ai flag automatici che possono essere attivati con la gestione Torn Page, che permette di avere la certezza di quello che viene scritto su disco, è possibile aggiungere un plus di sicurezza, ovvero un checksum di pagina che permette di effettuare, in caso di errore su disco, il ripristino della singola pagina rovinata con un sistema di "fast recovery" utilizzando (presumo) il log delle transazioni.
Non mi addentro oltre in tutto questo: sono dettagli davvero complessi su cui cimentarsi con l'rdbms sotto mano.

Ripristino dei dati
Anche per il Restore dei dati sono state introdotte nuove funzionalità e nuove funzioni per la verifica della correttezza dei supporti di Backup, siano essi dischi o nastri. E' addirittura possibile fare contemporaneamente due backup su due diversi device (due nastri o due dischi, presumo). Per una maggiore sicurezza.
Per quanto riguarda il restore, una delle novità è che non blocca il Database se non per il segmento legato al FileGroup che si sta ripristinando.
Dato che dubito che l'utente medio di un DB SQL server sappia cosa sono i filegroups ( in futuro ve ne potrei parlare in un articolo apposito), mi limito ad esortarvi: prendete la cosa per buona.

Di Hardware
Per quel che riguarda gli aggiornamenti dell'Hardware su cui SQL Server gira, dato che su Windows 2003 è possibile aggiungere Ram 'a caldo', Yukon di conseguenza sarà in grado di accorgersi della Ram aggiunta e di utilizzarla anche senza essere riavviato. Ho annotato qualcosa anche relativamente a CPU parallele, CPU affinity modificabile senza riavvio, ma potrei aver sentito male...

Sicurezza
Dopo le novità strutturali passiamo alla sicurezza: il catalogo del server (vedi DB Master) non sarà più accessibile in modo diretto agli utenti, ma sarà visibile tramite una serie di viste di sistema che permetteranno di accedere ai metadati come accade ora con "Select * from sysdatabases where nome = 'Pippo'" etc.
Ogni User avrà accesso alle viste sui metadati in base alle sue permissions.

E' stata effettuata una separazione fra utenti e oggetti (era ora!). Infatti, attualmente, ogni oggetto è identificato con il seguente percorso:

       server.database.user.oggetto, ovvero, ad esempio: [srv01].[northwind].[dbo].[employees]

Questo creava dei notevoli problemi ai DBA più coscienziosi, quelli che non lasciavano entrare tutti gli utenti come SysAdmin, perché, se l'aggiornamento di un database con creazione di tabelle veniva lanciato da un utente che non fosse un [dbo], gli oggetti del database creati appartenevano a detto utente e non erano visibili a tutti gli altri utenti del database (colui che non usa MSDE e fa parte del gruppo specificato nella prima riga di questo paragrafo, a cui questo non è mai accaduto, alzi la mano! ... BUGIARDO!!!).

Su Yukon, gli oggetti apparterranno invece ad uno schema e lo schema sarà poi mappato sugli utenti. Ogni Database potrà contenere più schemi in modo da far vedere agli utenti solo ciò che è di loro competenza.
Nell'esempio sopra ci sarà quindi:

       server.database.schema.oggetto, ovvero, ad esempio: [srv01].[northwind].[schema1].[employees]

Usando gli schemi si possono costruire i ruoli degli utenti.

Per quanto riguarda la sicurezza, Yukon supporterà tutte le funzionalità che sono supportate in Windows relativamente alla gestione Password; perciò: lunghezza minima, vietato riutilizzo della medesima password, scadenza delle password etc. Sarà obbligatorio mettere la password a SA anche se si attiverà la sola sicurezza Windows con Trusted connection (era ora!), il protocollo di autenticazione di SQL Server non manderà più le password in chiaro.

Per ognuna delle funzionalità, siano esse nuove o solo aggiornate, saranno disponibili sui Books online una serie di Best practices e di checklists per verificare quello che va predisposto dal lato amministrazione.
Ci saranno inoltre una serie di "Security Tools" per la verifica della security del sistema, per il controllo della vulnerabilità e l'installazione di patch relative alla sicurezza.

Problem Solving Tools
Passiamo ora a cosa fare quando le cose non vanno bene, ovvero quando gli utenti strepitano perché il gestionale è lento, perché non possono aspettare ore per ottenere i dati e simili situazioni in cui i DBA siedono sui carboni ardenti (dov'è il bugiardo di prima?).

Sono stati ridisegnati gli strumenti per l'analisi dello stato interno del server, per monitorare che cosa il server sta facendo, verificare perché è lento a rispondere oppure sembra essersi seduto a coloro che lo usano.
E' stato riscritto in modo più pratico e veloce il Tracer di SQL Server con la possibilità di monitorare molti più eventi e con una serie di schemi predefiniti più vasta. Inoltre non sarà necessario essere SysAdmin per poterlo utilizzare (Deo Gratias).
Sarà possibile attivare una connessione "dedicata" in caso di server instabile o bloccato che permetta al DBA di connettersi e capire cosa accade anche in casi estremi.
E' stata aggiunta la possibilità di generare eventi per tutte le operazioni di modifica tabelle, generazione tabelle etc. per poter effettuare l'auditing anche di questo genere di operazioni prima non monitorabili.
Nei tools sarà possibile salvare i profili del tracer in XML e poi effettuarne il "Replay" su un server di prova, in modo che, se si deve fare attività di ottimizzazione su query e similari, sia possibile fare dei test di tipo quantitativo.
Sono state aggiunte inoltre delle visualizzazioni grafiche comprensibili sia dei piani di esecuzione delle query che per il monitoraggio dei DeadLock.

Inoltre, incredibile ma vero, Yukon supporterà il protocollo SMTP e quindi l'invio di messaggi e-mail senza necessità di Exchange e di quelle cose poco pratiche che si doveva fare fino ad oggi.

Però... il Query analyzer e l'Enterprise manager non esisteranno più:

OMIODDIO!

Questo il commento di tutti noi poveri disgraziati DBA che viviamo di pane ed enterprise manager,
ma possiamo rilassarci: non ci saranno più perché la nuova IDE di SQL Server ovvero il SQL server Workbench sarà esattamente uguale a Visual Studio .NET. Completo di Intellisense e di tutti i gadget ad esso connessi. Tutte, ma proprio tutte, le operazioni che si compiranno su questa IDE sarà possibile registrarle e trasformarle in script T-SQL ripetibili

UUAAAAUU!

OSQL.EXE sarà sostituito da SQLCMD, che permetterà, oltre all'attuale esecuzione di script, di predisporre script parametrizzati (con variabili da inizializzare al volo) e il supporto della connessione di amministrazione.

Il Query analyzer vero e proprio sarà sostituito dal Database Tuning Advisor con una nuova interfaccia utente e una serie di nuove funzionalità, tra cui pure quella di suggerire modifiche alle query analizzate per migliorarne l'efficienza.

E per i programmatori???
Il fatto che l'IDE di SQL Server sarà quella di Visual Studio.NET dovrebbe dire qualcosa... Yukon supporta nativamente il CLR di .NET in process, perciò potremo scrivere in .NET (VB, C# e quant'altro) ed eseguire il codice in SQL Server.
E' chiaro che, se pure possiamo usare solo VB.NET per scrivere ciò che vogliamo eseguire in SQL Server, sarà consigliabile usare lo strumento per effettuare calcoli procedurali complessi e difficilmente traducibili in T-SQL e per effettuare complessi calcoli numerici in cui T-SQL non è efficiente: usare VB per procedure come l'UPDATE di un set di righe o simili sarebbe alquanto inefficiente anche se non vietato.
Il supporto di .NET integrato, inoltre, permetterà di effettuare tutte le operazioni del tipo accedere al file system oppure fare FTP o RPC senza dover passare per le extended stored procedure e attivare i contesti di sicurezza adatti alla loro esecuzione senza scomodare direttamente il SysAdmin unico per cui (chissà perché) tutto funziona sempre.

Il supporto di CLR e .NET indica anche che sarà possibile debuggare anche T-SQL esattamente come VB o C# e quindi mettere i BreakPoint virtualmente ovunque.
Visual Studio ospiterà ovviamente una serie di Template Projects ad hoc per SQL Server. Gli assembly prodotti in .NET saranno poi registrati in SQL Server e i metodi delle classi o le property saranno accessibili anche da T-SQL. Gli assembly registrati in SQL Server supporteranno il Versioning di .NET.

I nuovi dati
Oltre alle novità in fatto di strumenti, ci sono novità anche all'interno delle strutture,
per prima cosa quattro nuovi dati di sistema:

E tre tipi di dati implementati come UserDataTypes

Cosa sono gli UserDataTypes? Non certo i tipi dati utente che trovate nei miei articoli su MSDE: sono dei veri e propri tipi di dati che è possibile definire utilizzando una classe .NET con le loro proprietà e i loro metodi.
E' chiaro che non sono fatti per definire lo User Data Type Cliente e inserire una tabella con un solo campo (anche se nessuno vieta di usarli così): non è questo il loro scopo: è utile che questi tipi di dati user siano degli scalari anche se non hanno a che fare con i normali scalari di sistema. L'esempio portato è stato quello delle coordinate GIS.

Oggetti
La gestione oggetti in Yukon è Safe by default ovvero: tutto quello che io genero in modo standard da .NET viene compilato in managed code. E' chiaro che se io programmatore voglio fare delle cattiverie esistono altre due modalità che sono External Access da usarsi per tutto ciò che deve accedere direttamente a risorse esterne, conservando tutto quanto è possibile per rendere sicuro il codice. Poi c'è naturalmente l'Unmanaged code in cui si può fare tutto, compresi i disastri.

XML
Per quanto riguarda XML, sarà possibile, come già detto, creare dei campi di tipo XML navigabili e indicizzabili, sarà dato ampio supporto a XML per lo scambio dati, sarà possibile vedere una tabella SQL in XML e viceversa vedere XML come una tabella SQL (qui comunque direi che potremo pronunciarci in merito dopo aver visto in azione il tutto..., non per deliberato scetticismo, ma...)

WebServices
In Yukon ci sarà il supporto integrato per i WebServices tramite un HTTP EndPoint in grado di erogare direttamente i WebServices. Quindi sarà possibile costruire un WebService .NET e usare Yukon per farlo utilizzare. Qualcuno ha detto "allora farà da application server." Risposta MS: "Non è nato per quello, ma se serve..."

Per finire la panoramica sulle nuove features, ci sono una serie di funzioni simpatiche per il Ranking (ma non è detto che superino la Beta 1): servono per fare raggruppamenti statistici per ricorrenza di valori, certamente utili per coloro che di statistiche si occupano.

Linguaggio
Nel T-SQL sono state aggiunte le COMMON TABLE EXPRESSION, ovvero la possibilità di dare un nome ad un comando T-SQL e di usarlo all'interno di un altro comando T-SQL. Che è 'sta roba? Quello che serve per generare funzioni ricorsive in SQL fino a 2000 non ammesse. Il numero di livelli di ricorsione può essere stabilito dall'utente, altrimenti viene bloccato a 99 per evitare di uccidere il server ;o)
Sono stati aggiunti due comandi utili: PIVOT e UNPIVOT per "Girare" le tabelle
E' possibile effettuare il controllo errori con i blocchi TRY ... CATCH, anche se non così sofisticati come quelli di .NET, ed è possibile effettuare un Raiserror in una stored procedure per forzare l'ingresso nel blocco CATCH.
Sembra (trovo solo un cenno tra gli appunti) si possa fare trigger sul create table, ma non ricordo altro.
E' possibile avere una notifica eventi asincrona ovvero: il servizio BROKER (che se non erro sarà quello che si occuperà dei messaggi) sarà in grado di notificare, utilizzando XML, il verificarsi di eventi all'interno del server, e quindi di permettere ad esempio l'esecuzione asincrona di operazioni sui dati.
Utilizzando lo stesso sistema, sarà possibile mandare dei messaggi di notifica che possono permettere la costruzione e gestione di cache sul "mid tier" di una applicazione. Ci sarà un oggetto in ADO.NET fatto apposta allo scopo... (ma guarda la combinazione...)

La sessione mattutina si è conclusa qui, e se quanto detto sarà mantenuto e magari integrato con qualche finezza in più sulla Beta 2 credo che Yukon sarà un bello strumento.

Data Transformation Services
Passo ora alla sessione pomeridiana: Franco Perduca ha spiegato e dimostrato l'uso dei nuovi strumenti di Dts (Data Transformation Services) che permettono di costruire, a partire da un database OLTP (OnLine Transaction Processing) quali quelli con cui normalmente noi poveri DBA lavoriamo, un database OLAP (OnLine Analisys Process), ossia un Data Warehouse, dove costruire statistiche sui dati raccolti in produzione.
Lo strumento, così come gli altri strumenti dell'IDE di Yukon avrà un IDE integrata con Visual Studio, la possibilità di scriptare ogni cosa, la possibilità di effettuare il Debug momento per momento di ciò che si sta trasformando. E tutta una serie di innovazioni per la creazione vera e propria dei cubi di dati per l'analisi. Sarà possibile agganciare le elaborazioni al database di produzione per avere aggiornamenti quasi in tempo reale e, volendo, sarà possibile effettuare le elaborazioni senza creare i cubi se non virtualmente. Ci sono una serie di Wizard per aiutare i comuni mortali a creare le elaborazioni e, visto dal basso della mia ignoranza in materia di OLAP, sono dei tools quasi strabilianti.
Temo però che potrei dirvi di più solo dopo un'adeguata serie di corsi in materia, prima o poi prometto che li farò.
E' chiaro che anche in questi tools, come in quello che è il mio pane quotidiano, ovvero la parte più estesa di questa relazione, la possibilità di scrivere un oggetto in VB.NET per fare una trasformazione ai dati e agganciarlo ad una query T-SQL per passare i dati ad un'altra query SQL direttamente dentro a SQL Server è qualcosa che potrebbe far sbrodolare il programmatore così come un ragazzino davanti ad una torta di crema panna e cioccolata (non che anche i programmatori non si sbrodolino davanti alle torte ma spero accettiate il paragone...).

Concludo qui la mia serie di appunti su Yukon, molto di più probabilmente potranno dirci i fortunati partecipanti al PDC di Los Angeles, e qualcosina sono certa ci diranno coloro che parteciperanno alla molto italiana WPC a Novembre.
Mi piacerebbe essere fra loro, ma una settimana lavorativa è un bel po' di tempo (a prescindere dal costo di 1000 Euro)...
Vedremo.