Girando in rete ho trovato la prima bozza di un ebook in cui verranno descritte le novità più importanti di SQL Server 2012.

Riporto questo post per evitare di impazzire come me con le query MDX scritte a mano per Reporting Services. Stiamo parlando della proprietà MdxMissingMemberMode di una dimensione in Analysis Services. Questa proprietà è impostata di default su ignore cioè se io faccio riferimento ad un attributo che non esiste non mi da errore ad esempio "SELECT prodotti.categoria.caffeina" e caffeina non c'è non mi da errore. Se invece è impostata su "errore" allora mi segnalerà l'anomalia. Quindi se non vi trovate dei membri quando utilizzate le query MDX andate nelle dimensioni utilizzate e verificate tale proprietà vi farà risparmiare molto tempo. 

Per migliorare le prestazioni durante il process del cubo possiamo agire su una interessante proprietà legata all'attribute relationship. Un attribute relationship può essere "rigido" o "flessibile". Rigida significa che difficilmente quel rapporto cambierà ad esempio un mese sarà sempre univoco all'interno dell'anno. Flessibile invece quando potrebbe cambiare facilmente ad esempio non è detto che un dipendente appartenga sempre al stesso reparto. Il motore di analysis services mi da la possibilità di specificare quale tipo di relationship applicare all'attributo in tale modo può fare delle scelte sull'aggregazione. Infatti questa informazione aggiuntiva gli permette di risparmiare nel creare le aggregazione visto che costa crearle e quindi è più propenso a fare una aggregazione su un attributte relationship rigido che su uno flessibile.

Gli attribute relationship sono fondamentali per le prestazioni dei cubi. Non sono altro che delle relazionale tra gli attributi di una dimensione. Facciamo un esempio su una classica dimensione cliente. In una dimensione di questo tipo in genere abbiamo il comune la provincia e il codice del cliente. Di base il motore di Analysis services imposta gli attribute relationship dipendenti tutte dalla chiave quindi sia la provincia che il comune dipendono dalla chiave. In questo modo per sapere il comune devo sommare tutti i clienti di quel determinanto comune e successivamente se voglio sapere la provincia devo raggruppare tutti i clienti di quella provincia e quindi tutto dipende dalla chiave senza nessuna dipendenza. Se invece imposto un attribute relationship tra il codice cliente e il comune e tra il comune e la provincia significa che se conosco il comune in automatico conosco la provincia quindi non dipende più dalla chiave e a me basta sapere il comune per ottenere la provincia e questo mi comporta un miglioramento prestazionale in quanto non devo aggregare tutti i clienti del comune e poi tutti i clienti della provincia ma semplicemente aggregare solo i comuni della provincia. Si ha un miglioramento delle prestazioni perchè in questo modo il motore di Analysis Services conosce le relazioni tra i dati e questo migliora le aggregazioni.
Un documento interessante sulle prestazioni OLAP si trova qui.

Può essere interessante dare delle indicazioni sulle aggregazioni di un attributo al motore di Analysis Services. Questo lo si può fare utilizzando la proprietà AggregationUsage. Questa proprietà può assumere diversi valori a seconda di come voglio che il motore di Analysis Services si comporti durante la fase di aggregazione. Attenzione!!! che quello che con questa proprietà noi impostiamo sono solo delle indicazioni poi sarà il motore di Analysis Services che deciderà cosa fare.
I valori che posso assegnare alla UsageAggregation sono i seguenti:

• Full: cioè secondo me quell'attributo dovrebbe essere aggregato sempre.
• None: Non fare nulla
• Unrestricted: lasciamo scegliere al motore di analysis services senza indicare nulla
• Default: se l'attributo ha un membro All e se è chiave o fa parte di una gerarchia natuarale farà parte di una aggregazione(unrestricted) altrimenti niente(none).

Per modificare la AggregationUsage bisogna andare sulla tab del cubo che riporta l'etichetta "Aggregation" e si deve scegliere "Design Aggregations" come si vede nell'immagine sottostante.

Demo 1 - Ria Services

Demo 2 - Interoperability Out Of Browser

Di recente ho messo un post nel mio blog in cui ho mostrato uno script per modifiare lo schema di tutte le tabelle di database. Ora mostrerò uno script che permette di modificare lo schema di anche tutte le store procedure di un database. Lo script è il seguente:

SELECT 'ALTER SCHEMA MSSql31210 TRANSFER ' + s.Name + '.' + p.Name FROM sys.Procedures p INNER JOIN
sys.Schemas s on p.schema_id = s.schema_id

come si vede lo script non modifica direttamente le store ma semplicemente genera a video le istruzioni che dovrannoi essere eseguite. Quindi prima di eseguire lo script scegliere come output "Result to text" poi eseguire la select per generare il risultato che dovrà essere copiato ed incollato in una nuova query scegliendo come opzione di output: "Result to grid".

Spero come sempre di esservi stato di aiuto.

Di recente ho dovuto modificare lo schema a tutte le tabelle di un database. Per fare questo avevo trovato l'utilissima sintassi nel post del mio amico e collega Manuel Scapolan.
Questo post riporta come modifiare lo schema di una tabella: ALTER SCHEMA MSSql0001 TRANSFER dbo.be_Users , ma la mia necessità era modificare tutte le tabelle contemporaneamente. Allora ho costruito il seguente script:

sp_MSforeachtable "ALTER SCHEMA MSSql0001 TRANSFER ?"

che permette di modificare lo schema in tutte le tabelle.