Ben tornati a tutti (o quasi) dalle ferie, per me sono già finite da qualche giorno ma, come molti di Voi, sto ancora spalando le centinaia di mail accumulate durante il mese di Agosto. In genere qualche sorpresa capita sempre, e anche quest’anno l’aspettativa non è andata delusa emi sono ritrovato con una notizia, per gli addetti ai lavori, abbastanza sconvolgente, Ve la riporto con il post diretto dal Blog dei colleghi del team del “SQL Native Client”:
http://blogs.msdn.com/b/sqlnativeclient/archive/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access.aspx
The next release of Microsoft SQL Server, codename “Denali”, will be the last release to support OLE DB. OLE DB will be supported for 7 years from launch, the life of Denali support, to allow you a large window of opportunity for changing your applications before the deprecation.
OK, dopo un attimo di smarrimento cerchiamo di fare il punto e di “mitigare” lo sgomento:
http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-10-20-20-75/A-Quick-Guide-for-OLE-DB-to-ODBC-Conversion.docx
L’impatto sulle applicazioni è ovvio, ma ci sono altre considerazioni un po’ meno ovvie riguardanti, per esempio, i “Linked Server”, ADO.NET, SSIS, OLEDB Provider per DB2 e altre componenti Microsoft basate su OLEDB. Il seguente post ci dice qualcosa in merito a cosa succederà di qui aqualche anno:
http://social.technet.microsoft.com/Forums/en/sqldataaccess/thread/e696d0ac-f8e2-4b19-8a08-7a357d3d780f
Other Microsoft SQL Server features and products that are built on top of OLE DB or use OLE DB, like Distributed Query (Linked Server), SQL Server Integration Services, SQL Server Analysis Services etc., will continue to be supported as per their respective terms. Microsoft will take care of eplacing the underlying dependency.
P.S. = Qualche sospetto su un annuncio del genere già lo avevo da un paio di anni, quando con la nascita di “SQL Azure” l’OLEDB non è stato (e non è) incluso nei protocolli dati per l’accesso all’infrastruttura, a vantaggio di ODBC, PHP, ADO.NET, JDBC, etc. Un assenza molto sospetta…. :-)
Ah, un’ultima importante cosa, mi raccomando però di fare in fretta visto che scade il 9 Settembre prossimo: se volete dire la vostra o influenzare quello che Microsoft farà nel prossimo futuro per quanto riguarda la connettività a SQL, compilate la survey contenuta al link sottostante.
http://www.zoomerang.com/Survey/WEB22CS45XT9FE/
Buon lavoro a tutti.
--Igor Pagliai--
Post un po’ anomalo questo, ma visto che ultimamente sia clienti che colleghi mi hanno girato, in varie forme, la seguente domanda, perché non scriverci sopra due righe così la prossima volta girerò direttamente un link ?
La domanda è questa:
Perché l’acronimo SQL non viene pronunciato in stretta osservanza alla pronuncia inglese ?
In effetti è vero, il modo in cui viene pronunciato tale acronimo, che sta per “Structured Query Language” corrisponde al termine “SEQUEL” e non “SQL”.
Dopo un attimo di smarrimento iniziale mi sono ricordato di quanto mi aveva detto il mio vecchio professore di informatica delle scuole superiori (grazie prof.Vasellini ! :-) ) e da buon ex-IBM mi svelò il mistero i cui dettagli potete trovare su Wikipedia e di cui qui riassumo la frase chiave:
http://it.wikipedia.org/wiki/SQL
“….L' SQL nasce nel 1974 ad opera di Donald Chamberlin, nei laboratori dell'IBM. Nasce come strumento per lavorare con database che seguano il modello relazionale. A quel tempo però si chiamava SEQUEL (la corretta pronuncia IPA è [ˈɛsˈkjuˈɛl], quella informale [ˈsiːkwəl]). Nel 1975 viene sviluppato un prototipo chiamato SEQUEL-XRM; con esso si eseguirono sperimentazioni che portarono, nel 1977, a una nuova versione del linguaggio, che inizialmente avrebbe dovuto chiamarsi SEQUEL/2 ma che poi divenne, per motivi legali, SQL.”
Che dire ? Grazie Big Blue…. :-)
--Igor Pagliai—
Salve, periodo prolifico questo mese di Luglio, non appena una settimana fa è stata rilasciata la prima “Service Pack” (SP) per SQL Server 2008 R2, e già abbiamo la prima “Cumulative Update” (CU):
Cumulative update package 1 for SQL Server 2008 R2 Service Pack 1
http://support.microsoft.com/kb/2544793/en-us
NOTA: La build number della CU1 per SP1 di SQL 2008 R2 è “10.50.2769.0”.
Se non avete già letto il mio precedente post sulla SP1 di SQL 2008 R2, Vi invito a farlo ora a questo link per meglio comprendere quello che dirò in seguito:
http://blogs.technet.com/b/italian_premier_center_for_sql_server/archive/2011/07.aspx
Ed eccoci alla domanda cruciale che molti clienti fanno ad ogni rilascio della prima CU per ogni SP: “Ho appena installato la SP1 di SQL 2008 R2, devo anche installare la CU1 ?”
L’informazione fondamentale da tener presente è che la SP1 di SQL 2008 R2 contiene tutte le CU (per SQL 2008 R2 RTM) fino alla CU6 compresa, lasciando fuori quindi la CU7 (build 10.50.1777.0) e la CU8 (build 10.50.1797.0):
A supported cumulative update package is now available from Microsoft. However, it is intended to correct only the problems that are described in this article. Apply it only to systems that are experiencing these specific problems. This cumulative update package may receive additional testing. Therefore, if you are not severely affected by any of these problems, we recommend that you wait for the next SQL Server 2008 R2 service pack that contains the hotfixes in this cumulative update package.
OK, smarcata la CU1 per SQL 2008 R2 con SP1, diamo un’occhiata a quello che contiene la CU5 per SQL 2008:
Cumulative update package 5 for SQL Server 2008 Service Pack 2
http://support.microsoft.com/kb/2555408/en-us
NOTA: La build number della CU5 per SP2 di SQL 2008 è “10.00.4316.0”.
La prima importante informazione è che questa CU5 include la fix per il recente security bulletin MS11-049, se state sobbalzando sulla sedia perché pensate che sia il primo security bug di SQL 2008, allora non avete letto uno dei nostri precedenti post J:
http://blogs.technet.com/b/italian_premier_center_for_sql_server/archive/2011/06/27/il-primo-security-bug-per-il-database-engine-di-sql-2008.aspx
Per quanto riguarda la lista dei problemi fissati, ci sono diversi aggiornamenti molto importanti:
Incorrect results when you run an INSERT SELECT UNION ALL statement in SQL Server 2008
http://support.microsoft.com/kb/2530921/en-us
A backup operation on a SQL Server 2008 or SQL Server 2008 R2 database fails if you enable change tracking on this database
http://support.microsoft.com/kb/2522893/en-us
Recovery takes longer than expected for a database in a SQL Server 2008 environment
http://support.microsoft.com/kb/2524743/en-us
Infine, per gli amanti della replica di tipo transazionale e “merge”, un prezioso consiglio: installate questa CU perché ci sono due grossi problemi risolti relativi alla convergenza della prima e ad un crash dell’agent di replica per la secondo.
Buon lavoro a tutti….
Salve, avevamo promesso che su questo blog non saremmo mai scesi nel banale con post del tipo “E’ uscita la Service Pack tal dei tali, etc….”, non Vi preoccupate, scrivendo questo post non stiamo violando tale impegno, leggete e capirete che quello che sto per dirVi non è immediatamente deducibile dal marasma di link, readme, release notes e materiale vario che sta inondando Internet da questa notte.
Dunque, partiamo con la cosa fondamentale, il link per il download della SP1:
Microsoft® SQL Server® 2008 R2 Service Pack 1
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26727
Provate ad aprire questo link e Vi troverete una sorpresa:
E’ quello che sembra ? Posso confermarVi di si, dopo aver espanso i primi due package con il solito flag “-x”: questi due pacchetti, uno per piattaforma x86 ed uno per x64 per Itanium come è noto non c’è console SQL L, contengono gli aggiornamenti necessari per fissare il solo “SQL Server Management Studio e tutte le sue “dipendenze”.
La domanda meno banale è: “Ma se devo aggiornare un server dove sono installati sia il Management Studio sia il motore SQL, devo installare entrambi i pacchetti ?” In questo caso, il pacchetto principale è sufficiente per aggiornare tutto quanto, non c’è bisogno di una doppia installazione.
Altra questione che causa molta confusione è quella riguardante l’inclusione, in generale, delle varie Cumulative Update (CU) in ogni Service Pack (SP): dato che al momento della “chiusura” della lista delle hotfix da includere in una certa SP al momento del rilascio della suddetta SP passa del tempo, il ciclo di sviluppo delle CU va avanti, quindi una certa SP non include tutte le CU rilasciate al momento del rilascio della SP stessa. Frase un po’ contorta, lo ammetto, per dire che in questo caso la SP1 di SQL Server 2008 R2 include solamente le CU dalla (1) alla (6), ma non la (7) e la (8) ! Se avete, quindi, già installato la CU7 o la CU8 per SQL 2008 R2, è caldamente consigliato aspettare il rilascio della CU1 per SQL Server 2008 R2 SP1 , attenzione che questa CU è differente dalla dalla CU1 per SQL Server 2008 R2 in quanto si riferiscono ad una “base” diversa.
IMPORTANTE: La SP1 di SQL 2008 R2 contiene anche la fix necessaria per fissare il security bug MS11-049 di recente rilascio, magari se non lo avete già fatto andate a rileggerVi il mio precedente post sull’argomento per capire se effettivamente avete bisogno di questa security fix:
Il primo Security Bug per il Database Engine di SQL 2008 ?
Terzo ed ultimo punto di attenzione, ricordateVi che il pacchetto di aggiornamento di ogni Service Pack di SQL (SP), non include alcune componenti “accessorie” che devono essere quindi scaricate separatamente, come ad esempio:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26728
http://www.microsoft.com/download/en/details.aspx?id=9071
NOTA: Il link dei “ BooksOnline” è ancora in fase di aggiornamento, controllare la data e la versione di rilascio prima di scaricare.
Infine, è sempre bene ricordare che:
The SQL Server Service Cannot Start after You Uninstall SP1 for SQL Server 2008 R2 if a UCP Exists in the Instance of SQL Server
http://social.technet.microsoft.com/wiki/contents/articles/microsoft-sql-server-2008-r2-sp1-release-notes.aspx
How to slipstream SQL Server 2008 R2 and a SQL Server 2008 R2 Service Pack 1 (SP1)http://blogs.msdn.com/b/petersad/archive/2011/07/13/how-to-slipstream-sql-server-2008-r2-and-a-sql-server-2008-r2-service-pack-1-sp1.aspx
Credo sia tutto, ho in previsione di aggiornare questo post in caso si presentino “Known Issues” sulla SP1 di SQL 2008 R2, quindi Vi consiglio di controllare periodicamente questo blog :-) ....
Buon lavoro a tutti !
Salve, questo mese l’oggeto del presente post è passare in rassegna le hotfix contenute nelle ultima “Cumulative Update” (CU8) per SQL 2008 R2 e gli eventuali punti di attenzione, avvertenze ed eventuali problemi. Prima di andare avanti, però, è bene ricordare la policy ufficiale Microsoft menzionata nel post seguente:
http://blogs.technet.com/b/italian_premier_center_for_sql_server/archive/2011/05/24/devo-installare-l-ultima-cumulative-update-cu-di-sql-server-un-nuovo-servizio-dal-gruppo-italian-premier-center-for-sql-server-solo-per-i-clienti-italiani.aspx
L’articolo ufficiale del presente aggiornamento è il seguente;
Cumulative Update package 8 for SQL Server 2008 R2
http://support.microsoft.com/kb/2507770/en-us
La “build” di questo aggiornamento è la “10.50.1797.0”, come al solito potete trovare la lista completa dei precedenti aggiornamenti al seguente link:
The SQL Server 2008 R2 builds that were released after SQL Server 2008 R2 was released
http://support.microsoft.com/kb/981356
Al momento del download della specifica CU, attenzione che avrete più di un file a disposizione, assicuratevi di scaricarli tutti e provvedere eventualmente all’installazione in base ai componenti installati; la presente CU contiente infatti i seguenti pacchetti (per x64):
Per quanto riguarda questo aggiornamenti, segnaliamo le due seguenti importanti hotfix:
FIX: "A time-out occurred while waiting for buffer latch" error when many transactions concurrently update a database in SQL Server 2008 R2 if the database uses the snapshot isolation level
http://support.microsoft.com/kb/2545989/en-us
FIX: A backup operation on a SQL Server 2008 or SQL Server 2008 R2 database fails if you enable change tracking on this database
Nel dettaglio:
NOTA: Lo stesso problema è presente anche in SQL Server 2008 SP1.
Ricordiamo inoltre che:
Anche per questa CU è tutto, buon lavoro a tutti.
-- Igor Pagliai--
Sebbene non sia un problema recente, ho deciso di creare questo post sul nostro blog per cercare di fare chiarezza su un problema strisciante, sebbene non grave, che da diverso tempo affligge SQL Server 2008 dalla “Service Pack 1” in poi e che, fino ad oggi, non ha avuto l’onore di avere un articolo di Knowledge Base Microsoft ufficiale. Cercando di visualizzare uno degli “Standard Reports” dal SQL Management Studio, Vi è mai capitato di ricevere il seguente errore ?
A beneficio dei motori di ricerca, includo anche la stringa completa del messaggio di errore sicuro che i motori di indicizzazione renderanno questo post visibile:
The file 'Microsoft.ReportViewer.WinForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' cannot be opened. Do you want to remove the reference from the Recent list?
In base alla mia esperienza diretta, questo problema ha iniziato a manifestarsi a partire dalla CU3 per SQL Server 2008 SP1, è continuato con la CU4, è stato apparentemente risolto con il rilascio della CU5 ma si è ripresentato sia in CU8 per SP1 che con la CU2 per SP2. Al momento, come ho avuto modo di testare direttamente, il problema non si è manifestato con SQL Server 2008 R2 in versione definitiva, dove avrebbe dovuto essere fissato (e così sembra almeno fino ad ora) dato che in alcune versione pre-release l’inconveniente era stato riscontrato:
https://connect.microsoft.com/SQLServer/feedback/details/523972/sql-2008-r2-nov-ctp-management-studio-reports-fail-on-opening
La difficoltà nell’accertare con certezza quali CU e quali SP sono afflitte dal problema sta nel fatto che i Clienti si trascinano dietro il problema da tempo e non subito se ne accorgono, e dal fatto che è un problema che affligge solo la console di SQL ed essendo questa installata in giro per molte macchine, non solo sui server di produzione dove a dire la verità non dovrebbe stare. In ogni modo, la soluzione a questo problema è molto semplice e non richiede alcun reboot, è sufficiente (re)installare la seguente componente su tutte le macchine dove si trova installato il “SQL Server Management Studio (SSMS)”, non necessariamente quelle dove è installato il database engine di SQL Server 2008:
Microsoft Report Viewer 2008 SP1 Redistributable
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=bb196d5d-76c2-4a0e-9458-267d22b6aac6
-- Igor Pagliai --
Come promesso, eccoci al primo appuntamento dedicato ai Workshop e ai Servizi a Valore di cui si occupa il nostro gruppo.
Ne approfittiamo subito per parlare di un corso appena introdotto nel nostro catalogo.:
SQL Server 2008 for Relational Database Developers
Si tratta di un corso (3giorni base + 1 giorno di corso avanzato opzionale) dedicato agli sviluppatori T-SQL, che fornirà ai partecipanti le conoscenze necessarie per programmare con SQL Server 2008.: i toolset, best practices di sviluppo, le nuove features a disposizione. Il corso comprende presentazioni, dimostrazioni e sezioni hands-on-lab che aiuteranno i partecipanti a rinforzare i concetti appresi e a sviluppare le conoscenze acquisite.
Oltre a questo nuovo corso dedicato agli sviluppatori T-SQL, il nostro catalogo include altri due workshop dedicati a chi non copre direttamente il ruolo di Database Administrator, ma che in qualche modo deve interfacciarsi con l'engine per svolgere le proprie attività.
SQL Server 2008 for Non-SQL Administrators
Si tratta di un corso di 2 giorni dedicato alle organizzazioni che non hanno risorse dedicate all'amministrazione di SQL Server, ma che devono supportare istanze di SQL Server critiche, come backend di applicazioni come Microsoft Sharepoint, Microsoft System Center Configuration Manager (SCCM), Microsoft System Center Operations Manager (SCOM), Microsoft BizTalk Server.
Il corso fornisce un introduzione al SQL ServerDatabase Engine (configurazioni base, maintenance plans, performances) ed include hands-on-lab per fornire ai partecipanti la confidenza necessaria per gestire un istanza SQL Server 2008.
SQL Server for SharePoint Administrators
Questo workshop è dedicato agli amministratori di Microsoft Windows Sharepoint Services 3.0, Microsoft Office Sharepoint Server 2007, Sharepoint Foundation 2010 e Sharepoint Server 2010 e fornisce le conoscenze e le competenze necessarie per configurare correttamente e gestire (monitoraggio e piani di manutenzione) le istanze di SQL Server implementate come backend. Il corso include anche una sezione dedicata al performance troubleshooting, e discute le opzioni disponibili per l'implementazione di scenari di High Availability e Disaster Recovery.
Se siete interessati, o desiderate ricevere maggiorni informazioni,vi consigliamo di contattare il vostro riferimento Microsoft Premier.
A presto!
- Beatrice Nicolini -
Salve, sicuramente sarete al corrente del Security Bulletin “MS11-049” , uscito circa due settimane fa, e sono altrettanto sicuro che Vi sarete detti: “Anche SQL Server 2008, dopo ben 3 anni di assoluta immunità dai bug di sicurezza, ha avuto la sua prima vulnerabilità”.
Mi dispiace per gli amici di Oracle, IBM DB2 e MySQL, ma dovranno aspettare ancora prima di pronunciare una frase del genere, dato che il Security Bulletin in oggetto non riguarda il “Database Engine” di SQL, bensì una sola DLL che fornisce la funzionalità di editing XML ad alcune delle console della famiglia dei prodotti SQL Server che Vi potreste trovare ad installare.
Ma andiamo con ordine partendo dall’articolo di riferimento per il Security Bulletin “MS11-049”:
MS11-049: Vulnerability in the Microsoft XML Editor could allow information disclosure: June 14, 2011
http://support.microsoft.com/kb/2543893/en-us
Microsoft Security Bulletin MS11-049 - Important
Vulnerability in the Microsoft XML Editor Could Allow Information Disclosure (2543893)
http://www.microsoft.com/technet/security/bulletin/MS11-049.mspx
Il file/dll coinvolta è la "Microsoft.xmlEditor.dll", originariamente la vulnerabilità è stata scoperta nella versione 2008 di Visual Studio: tramite questa vulnerabilità, è in teoria possibile copiare un file locale verso una destinazione remota, nel caso si riesca a far aprire all'utente un vile XML appositamente costruito.
Questo problema di sicurezza, quindi, non riguarda il database engine di SQL Server (SQLSERVR.EXE), quindi la Vostra installazione è ancora “sicura”, a meno che non abbiate installato, in locale al/ai server, una delle console dei prodotti della famiglia “SQL Server” che si basano su Visual Studio: è bene ricordare che, in genere, è sconsigliato installare qualsivoglia tipo di console sui server di produzione SQL, ivi inclusi il Management Studio e/o Il Business Intelligence Development Studio (BIDS per gli amici). Questo Security Bulletin è un ulteriore buon motivo per seguire questa best practice, quindi, ma è anche un avvertimento affinchè la relativa hotfix sia installata non solo sui server di produzione/test/svilluppo, ma anche sui desktop degli Amministratori SQL dove è normale prassi installare le console di gestione di SQL Server.
Un semplice consiglio: se non siete sicuri di avere o meno una delle console di SQL Server affette dal problema di sicurezza specifico, fate una semplice “File Search” per la DLL coinvolta e verificate in maniera inoppugnabile; fate anche attenzione al nome del file, ci sono varie DLL dal nome simile, ma quella che a Voi interessa è solamente “Microsoft.xmlEditor.dll”.
Forse perché è il primo “Security Bulletin” in 3 anni per SQL 2008, ed il terzo per SQL 2005 in 6 anni, e quindi i Clienti SQL non ci sono abituati, ma il rilascio di questo “Bulletin” ha generato alcune domande che riassumo qui di seguito, unitamente alle relative risposte, in modo che tutti possano beneficiarne:
- Q1: Come faccio a sapere quale fix installare per una certa “build number” di SQL Server ?
- Q2: Cosa significano GDR e QFE ?
Description of the standard terminology that is used to describe Microsoft software updates
http://support.microsoft.com/kb/824684/en-us
- Q3: Se l’unico file impattato dal bug di sicurezza è la DLL “Microsoft.xmlEditor.dll” ed è poco più di 1MB, perché sia i pacchetti GDR che QFE sono diverse centinaia (a seconda della versione) di MB ?
Anche per questo post è tutto, per il primo articolo su un security bug di SQL 2008 dovrete attendere ancora ! :-)
Approfittiamo di questo blog per condividere (e pubblicizzare :-)) alcuni tra i Workshop e i Servizi a Valore di cui si occupa il nostro team.
Il nostro catalogo è in continuo aggiornamento. Ogni anno, o meglio ogni mese, nuovi contenuti vengono aggiunti e altrettanti vengono eliminati, in uno sforzo costante di rimanere al passo con le versioni (e le features incluse in ogni versione) di SQL Server.
Il nostro catalogo include due tipologie di attività che possiamo erogare presso i nostri clienti, in particolare Workshop e Servizi a Valore.
Ad oggi è formato complessivamente da.:
16 Workshop dedicati al Database Engine.:
5 Workshop dedicati alla Business Intelligence.:
4 Servizi a Valore dedicati al Database Engine.:
1 Servizio a Valore dedicato ad Analysis Services.:
Nel nuovo tag di questo blog (Tag.: "Catalogo"), a partire da oggi, più o meno settimanalmente, vogliamo approfondire i singoli contenuti del nostro catalogo, entrando nel merito di ogni contenuto descrivendone i temi trattati, sperando di potervi essere di aiuto nel capire se una o più di queste attività vi possa risultare utile e chiedendovi in cambio i vostri feedback rispetto agli argomenti inclusi nel catalogo, ad esempio nel caso in cui riteniate che alcuni argomenti siano mancanti.
Buona lettura!
Durante una recente attività da un Cliente, mi è stata presentata una problematica con un (ahimè !) ben noto preambolo: “SQL Server ha un bug !”. E’ vero, questo può accadere, ma l’esperienza insegna che spesso le conclusioni sono tratte in maniera affrettata, tanto più che è necessaria una conferma “ufficiale” da una persona Microsoft in grado di verificare la porzione di codice sorgente interessata. Perché questo cliente era così convinto ? Bè, ascoltando i sintomi riscontrati devo dire che tutti i torti non li aveva, giudicate Voi:
Error: 605, Severity: 21, State: 3.
Attempt to fetch logical page %S_PGID in database 2 failed.
It belongs to allocation unit %I64d not to %I64d.
Errore 605 ? Molto brutto come tutti i DBA, che hanno avuto almeno un caso di corruzione di database nella vita, sanno bene ! Effettivamente non si può dare torto ad un DBA se la parola bug viene pronunciata, ma ad un esame più attento del messaggio di errore, il DBA doveva subito insospettirsi del fatto che la corruzione riguarda il database con ID = 2 e cioè il TEMPDB; pensateci bene:
Se sommate queste due cose insieme, quello che siete autorizzati a pensare è che la corruzione sia, per così dire, svanita perché l’oggetto in TEMPDB non esiste più…. In questo caso ci avete azzeccato, complimenti !
Quindi, direte Voi, è un bug !
Mi dispiace, so che tutte le persone Microsoft sono estremamente riluttanti ad ammetterlo, ed io non faccio eccezione, ma non è proprio così :-); dunque, il problema in oggetto è ben noto, si tratta effettivamente di un bug di SQL Server 2008 ma non di SQL Server 2008 R2 (la versione nel nostro caso), quindi tecnicamente:
FIX: You receive error 605 and error 824 when you run a query that inserts data into a temporary table in SQL Server http://support.microsoft.com/kb/960770/en-us
La spiegazione di tutto è nella strategia adottata da Microsoft per “attivare” alcune fix che, sebbene risolvano effettivamente una certa classe di problemi, potrebbero impattare la compatibilità applicativa introducendo delle modifiche a come il “Query Optmizer” di SQL Server lavora: per non generare questo tipo di problemi, per una particolare e ristretta categoria di hotfix, oltre ad installare una certa patch è anche necessario abilitare un particolare “trace flag” per rendere operativa la modifica già presente nel codice:
Trace flag 4199 is added to control multiple query optimizer changes previously made under multiple trace flags http://support.microsoft.com/kb/974006/en-us
Quindi, nel nostro caso con SQL Server 2008 R2 (versione RTM), la fix al problema era già inclusa nel codice del prodotto, ma non era attiva perché richiedeva l’attivazione mediante “trace flag”: dopo aver abilitato il trace flag “-T4135” (???) il problema non si è più ripresentato, evviva !
E’ stato un piacere, si è fatto tardi…. arrivederci e buon lavoro !
Ehi, un momento, frena: Microsoft, tu mi hai detto che la fix è già inclusa in SQL 2008 R2, che basta attivarla con il trace flag “-T4199” come dici nell’articolo, e poi usi un trace flag differente ? Ci devi una spiegazione !
Ci ho provato, ma mi è andata male ! :-)
Nel suddetto articolo, c’è una piccola nota, del tipo delle postille nei contratti di assicurazione o delle banche:
* Note In SQL Server 2008 R2 release version, the trace flag 4135 was inadvertently omitted from the list of trace flags that can be controlled by -T4199. But this has been fixed in Cumulative Update 1 for SQL Server 2008 R2. So, for this build and for SQL Server 2005 and SQL Server 2008 supported editions, -T4199 will suffice to enable this and other trace flags that are listed in this article.
A causa di un bug (ehm !), l’attivazione della fix per il problema doveva avvenire tramite trace flag “-T4199” ma non è stato così per cui nella versione “RTM” (pre CU1 per SQL Server 2008 R2), è necessario utilizzare un trace flag differente, cioè il “-T4135”. Se avete una versione eguale o successiva alla CU1 (per SQL Server 2008 R2) allora state tranquilli ed utilizzate il trace flag “-T4199”.
Stavolta, veramente, Vi auguro buon lavoro e mi congedo da Voi. Alla prossima !
- Igor Pagliai -
Le Opinioni espresse in questo blog sono strettamente personali e riflettono il punto di vista dell’autore/degli autori in base alla propria esperienza e conoscenza.
I contenuti di questo blog inoltre non rappresentano (necessariamente) le opinioni di Microsoft e non costituiscono alcuna garanzia ne’ conferiscono alcun diritto.
Come preannunciato nel precedente post di questo blog, iniziamo una serie di post periodici per segnalare, e porre in evidenza, le hotfix contenute nelle ultime “Cumulative Update” (CU) per SQL 2008 e SQL 2008 R2, che ogni DBA dovrebbe seriamente prendere in esame, fermo restando la policy ufficiale Microsoft menzionata nel post seguente: http://blogs.technet.com/b/italian_premier_center_for_sql_server/archive/2011/05/24/devo-installare-l-ultima-cumulative-update-cu-di-sql-server-un-nuovo-servizio-dal-gruppo-italian-premier-center-for-sql-server-solo-per-i-clienti-italiani.aspx
Questo mese ci occupiamo delle seguenti (CU):
Cumulative update package 4 for SQL Server 2008 Service Pack 2 http://support.microsoft.com/kb/2527180/en-us
[Build 10.00.4285 rilasciatail 16 Maggio 2011]
Cumulative Update package 7 for SQL Server 2008 R2 http://support.microsoft.com/kb/2507770/en-us
[Build 10.50.1777.0 rilasciata il 18 Aprile 2011]
Per quanto riguarda la CU4 per SQL Server 2008 SP2, segnaliamo le seguenti importanti hotfix:
FIX: Database corruption if data compression enabled on a partitioned table in SQL Server 2008 http://support.microsoft.com/kb/2548593/en-us
FIX: Computer stops responding when you create a database that contains a FILESTREAM filegroup in SQL Server 2008 or in SQL Server 2008 R2 if a third-party mini-filter driver is installed http://support.microsoft.com/kb/2435404/en-us
FIX: SQL Server Browser service periodically does not respond to incoming requests http://support.microsoft.com/kb/2526552/en-us
FIX: An access violation occurs when you restore a database and run the sp_replcounters stored procedure at the same time on a server that is running SQL Server 2008 http://support.microsoft.com/kb/2535705/en-us
Alcune note sulle suddette hotfix:
Per quanto riguarda, invece, la CU7 per SQL Server 2008 R2, segnaliamo le seguenti importanti hotfix:
FIX: Assertion error when you try to recover a database in SQL Server 2008 R2 http://support.microsoft.com/kb/2503834/en-us
FIX: Access violation when you insert data into a new partition of a partitioned table after you drop a column of the table in SQL Server 2008 R2 http://support.microsoft.com/kb/2504090/en-us
FIX: "Exception 0xc0000005 EXCEPTION_ACCESS_VIOLATION" and SQL Server 2008 R2 crashes when you start a SQL Server Extended event session and perform actions that are bound to events in the Xevent session on a case-sensitive database http://support.microsoft.com/kb/2515489/en-us
FIX: Non-yielding scheduler error when you run a query that uses a TVP in SQL Server 2008 or in SQL Server 2008 R2 if SQL Profiler or SQL Server Extended Events is used http://support.microsoft.com/kb/2520808/en-us
FIX: Application performance issue when a query references temporary tables that are created in a session in SQL Server 2008 and in SQL Server 2008 R2 http://support.microsoft.com/kb/2526959/en-us
Infine, ricordo a tutti i due articoli di riferimento per tenere traccia di tutti i rilasci delle (CU) per SQL 2008 SP2 e SQL 2008 R2 RTM (RTM = Release to Manifacturing = no SP):
The SQL Server 2008 builds that were released after SQL Server 2008 Service Pack 2 was released http://support.microsoft.com/kb/2402659/en-us
The SQL Server 2008 R2 builds that were released after SQL Server 2008 R2 was releasedhttp://support.microsoft.com/kb/981356/en-us
E con questo è tutto, buon lavoro a tutti ed al prossimo post.
DISCAIMER.:
1) La lista delle hotfixes che verranno segnalate nel presente blog non ha la pretesa di essere esaustiva: verranno scelte solo quelle di grande e generale impatto. Per una lista completa delle hotfixes contenute in ogni CU rilasciata è necessario fare riferimento ai seguenti articoli:
The SQL Server 2008 R2 builds that were released after SQL Server 2008 R2 was released http://support.microsoft.com/kb/981356/en-us
2) Le informazioni contenute non costituiscono alcuna modifica alle policy ufficiali Microsoft, e sono da considerarsi solo un mezzo informativo a disposizione dei DBA;
3) Le segnalazioni non costituiscono alcuna garanzia di compatibilità e/o funzionalità per gli aggiornamenti riportati, le canoniche policy di “change management” proprie di ogni Cliente devono essere comunque ottemperate;
L’argomento è delicato in quanto il lecito desiderio di ogni DBA di evitare certi problemi a priori, si scontra con quelle che sono le “best practices” Microsoft in termini di installazione degli aggiornamenti per SQL Server (e non solo), in particolare per le “Cumulative Update” (CU).
Il meccanismo delle “Cumulative Update” (CU), in uso da alcuni anni da SQL Server 2005 in poi (e su altri prodotti Microsoft) ha dato ottimi risultati in termini di modularità dei rilasci (più hotfix in bundle), regolarità degli aggiornamenti (periodicità bimestrale) e qualità dei test svolti da Microsoft (regression test). E’ bene sottolineare che una “Cumulative Update” (CU) non è equivalente ad una “Service Pack” (SP) ma ci va molto vicino, inoltre permette di ridurre anche l’impatto delle modifiche da testare, dato che si tratta di un numero decisamente inferiori di modifiche al codice sorgente.
Dopo questa doverosa premessa, ecco la domanda che spesso mi viene rivolta dai Clienti: “Devo installare l’ultima CU rilasciata per SQL Server ?”.
Fatemi prima rispondere come “engineer” Microsoft, mostrandoVi un tipico estratto da uno degli articoli relativi al rilascio delle varie (CU), nello specifico la CU4 per SQL Server 2008 SP2:
A supported cumulative update package is now available from Microsoft. However, it is intended to correct only the problems that are described in this article. Apply it only to systems that are experiencing these specific problems. This cumulative update package may receive additional testing. Therefore, if you are not severely affected by any of these problems, we recommend that you wait for the next SQL Server 2008 service pack that contains the hotfixes in this cumulative update package.
Sembra abbastanza chiaro, Microsoft raccomanda di applicare la specifica (CU) solo se contiene la fix relativa ad un problema specifico che Voi avete riscontrato, altrimenti è meglio aspettare la prossima (SP).
C’è un primo problema non trascurabile nel seguire quella che è una policy assolutamente basata sul buon senso, e che condivido in pieno, cerco di illustrarvelo citando uno dei problemi “fissati” nella medesima CU4 per SQL Server 2008 SP2:
Impressionante, vero ?
Immaginate di ricadere nella situazione specifica: Vi ritrovate con un database corrotto e sebbene Voi abbiate sicuramente una robusta e collaudata politica di backup (vero ? :-)), comunque il Vostro ambiente di produzione avrà un non trascurabile impatto dovuto alle necessarie operazioni di troubleshooting per capire cosa è successo e alle seguenti ed inevitabili operazioni di restore.
Forse sarebbe meglio evitare, Voi cosa dite ?
Altro problema che potreste avere seguendo alla lettera la suddetta policy negli aggiornamenti, ecco un altro bug/articolo di esempio:
FIX:A query that has a CONTAINS predicate in a WHERE clause takes a long time to compile in SQL Server 2008 or SQL Server 2008 R2 http://support.microsoft.com/kb/2491510/en-us
Già, I problemi di performance: talvolta I DBA non se ne accorgono subito, magari la dotazione hardware dei server è tale da mitigare/nascondere tali problemi, ma non sarebbe meglio evitare a priori ?
In base a quanto detto finora in questo post, appare chiaro (spero !) che comunque la policy di Microsoft, nello specifico per SQL Server per quanto riguarda l’applicazione delle (CU) rimane assolutamente valida, io ci aggiungerei una piccola postilla:
Il DBA dovrebbe periodicamente controllare le CU rilasciate e verificarne la lista dei problemi fissati, quindi valutarne l’impatto, qualora esista, sul proprio ambiente di produzione, infine considerare il rischio inerente alla mancata applicazione del suddetto aggiornamento.
Come spesso accade, quello che crea problemi ai DBA è la mancanza di tempo, rivedere tutte le CU periodicamente non è proprio un’attività trascurabile, in ogni modo se volete farlo ecco due utilissimi articoli per tenere traccia delle ultime CU disponibili per SQL Server 2008 e SQL Server 2008 R2:
IMPORTANTE: Attenzione che ogni (CU) è specifica per una certa (SP), i suddetti articoli quindi cambieranno al rilascio di una nuova (SP).
Chiedo scusa agli utilizzatori di SQL Server 2005 ma oramai il prodotto è entrato in “Extended Support” e non ha quindi più molto senso seguirne le relative CU che a breve termineranno.
Per finire, ecco cosa il nostro gruppo vorrebbe fare per Voi: mettere in evidenza, quindi pubblicare periodicamente su questo blog, le hotfix contenute nelle (CU), che da ora in poi verranno rilasciate da Microsoft per SQL Server 2008 e SQL Server 2008 R2, e che rivestono particolare importanza per la stabilità e le performance di SQL Server.
E’ un impegno non trascurabile, ma credo che sia un servizio utile per i Clienti che ci onorerano della loro attenzione, devo però includere due importanti “disclaimer”:
Spero che questa iniziativa incontri il Vostro favore, ogni commento o critica sarà bene accetto.
Buon lavoro ed appuntamento al prossimo post !
Nel precedente post http://blogs.technet.com/b/italian_premier_center_for_sql_server/archive/2011/05/13/ha-senso-avere-pi-249-di-64-cpu-per-sql-server-2008.aspx abbiamo approfondito come sfruttare pienamente la disponibilità di un numero maggiore di 64 CPU logiche con Windows Server 2008 R2 e SQL Server 2008 R2. Uno dei punti affrontati era relativo al fatto che il tradizionale meccanismo dell’ “Affinity Mask”, disponibile in SQL Server da molte versioni, non era di fatto utilizzabile.
In passato, questo meccanismo è stato raramente utilizzato, ma con la disponibilità sul mercato di server equipaggiati con i più recenti modelli di CPU multi-core, sia da Intel che da AMD, la necessità di poter stabilire un’affinità statica tra le CPU logiche ed il processo SQL Server è tornata in auge.
Come per altre “features” introdotte da SQL Server 2008 R2, lo statement “ALTER SERVER CONFIGURATION” è passato pressochè inosservato, ma è una assoluta novità di questa versione di SQL Server (non esiste in SQL Server 2008) e permette, per l’appunto, di gestire le CPU logiche usate dal database engine di SQL Server in maniera estremamente granulare, oltre il limite delle 64 unità e fino ad un massimo di 256: http://msdn.microsoft.com/en-us/library/ee210585.aspx
NOTA: Come si può vedere nella parte evidenziata, questa funzionalità è disponibile solo in SQL Server 2008 R2 e in “Denali”, cioè la prossima versione di SQL Server; Osservando con attenzione la sintassi di questo comando, ci si può subito rendere conto che, nonostante l’apparente generalità dello statement (“ALTER SERVER CONFIGURATION”), almeno nella corrente versione di SQL Server, l’unica cosa che può gestire è l’affinità delle CPU, niente altro.
Prima di analizzare più a fondo le possibilità di questo comando e le relative implicazioni a livello di Sisteam Operativo, è bene introdurre un esempio significativo in modo da rendere più chiari i concetti successivi:
Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) Apr 2 2010 15:48:46
Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7600: )
Con una rapida verifica in Task Manager, o tramite uno dei molteplici script TSQL di diagnostica, in questo specifico caso abbiamo a disposizione ben 80 CPU “logiche”: (4 CPU) x (10 CORE) x HT = 80. Ben più interessante è la seguente porzione dell’ERRORLOG di SQL Server, nella parte iniziale dove sono tracciate tutte le informazioni relative al “bootstrap” dell’istanza:
Sicuramente alcune persone avranno già riconosciuto questo stralcio dell’ERRORLOG e sapranno cosa significa: questo server viene “visto”, da Windows e da SQL, come una macchina ad architettura NUMA con 4 nodi e con specifici gruppi di CPU assegnati ad ognuno; solo i più attenti, però, avranno notato una piccola ma significativa differenza con quello che normalmente appare con SQL Server 2008, e cioè la singola cifra evidenziata in rosso che appare alla fine di ogni riga. Di che cosa si tratta ? Prima di rispondere a questa domanda due importanti approfondimenti che è bene conoscere prima di proseguire nella lettura di questo post:
1) Come SQL Server (>= 2005) supporta e trae beneficio dalle architetture NUMA:
Understanding Non-uniform Memory Access http://msdn.microsoft.com/en-us/library/ms178144.aspx
How SQL Server Supports NUMA http://msdn.microsoft.com/en-us/library/ms180954.aspx
2) Come Windows Server 2008 R2 “vede” le macchine con più di 64 CPU logiche:
Running SAP Applications on SQL Server
http://blogs.msdn.com/b/saponsqlserver/archive/2010/09/28/windows-2008-r2-groups-processors-sockets-cores-threads-numa-nodes-what-is-all-this.aspx
Questo secondo punto è basilare e spiega la cifra evidenziata in rosso a cui ho fatto precedentemente riferimento: nell’estendere la capacità di Windows oltre il limite delle 64 CPU logiche, è stato introdotto il concetto di “Processor Group” (o “K-group” come a volte viene altresì chiamato), e cioè una ulteriore unità di raggruppamento delle CPU in sottoinsiemi di massimo 64 unità, come ben chiarifica il seguente diagramma:
Ebbene, quella famosa cifra evidenza proprio il “Processor Group” (PG) al quale lo specifico nodo NUMA appartiene, così come le CPU/CORE che ne fanno parte come riportato dalla relativa bitmap; con questa nuova importante informazione rileggiamo la parte di ERRORLOG già evidenziata:
E’ evidente che qualcosa di strano c’è dato che un PG è composto da 60 CPU logiche (PG[1]) mentre l’altro (PG[0]) solo da 20 ! In realtà non c’è nulla di strano, la definizione di “Processor Group” (PG) dice che può includere fino a 64 CPU logiche e non è riportato da nessuna parte che la suddivisione debba per forza essere uniforme nel numero di CORE tra un PG e l’altro. In questo caso, infatti, su un totale di 80 CPU logiche, 20 sono assegnate al PG[0] e rappresentano di fatto una singola (la prima !) CPU (10 CORE x HT = 20) e nodo NUMA[1], mentre le altre 60 sono assegnate al PG[1] e rappresentano le altre 3 CPU (3 x 10 CORE x HT = 60) per i nodi NUMA[ 0],[2] e[3].
La seconda cosa strana è: perché al primo nodo NUMA ([0]) corrisponde un set di CPU del secondo “Processor Group” (PG[1])? La risposta a questa domanda richiederebbe un post a parte, magari scritto da un collega esperto di Sistemi Operativi, qui è sufficiente sapere che in SQL Server vengono invertite le CPU usate dai primi due nodi NUMA ([0] e [1])per evitare che alcuni dei task di sistema/default di SQL Server si trovino in esecuzione sugli stessi CORE dove girando alcuni dei task di sistema/default di Windows.
Se la cosa Vi sembra complicata, ed effettivamente ad un certo grado lo è, potete usare il tool “COREINFO” di “Sysinternals” per conoscere i dettagli delle CPU, CORE, HT, Processor Groups, etc:http://technet.microsoft.com/en-us/sysinternals/cc835722
Il tool fornisce veramente molte informazioni utili, specialmente per quanto riguarda la numerazione dei CORE, delle CPU, dei NUMA nodes e dei “Processor Group” (PG), la velocità di accesso alla memoria non locale di ogni nodo NUMA, etc; in allegato (coreinfo_result.txt) ho riportato un esempio ottenuto dalla macchina di test precedentemente citata.
Dopo questa lunga digressione, siamo infine in grado di capire come impostare l’utilizzo di CORE, CPU, PG per la nostra istanza SQL Server 2008 R2, ecco alcuni tipici esempi sul nostro hardware di riferimento:
1) Utilizzo del solo NUMA node [0]:
ALTER SERVER CONFIGURATION SET PROCESS AFFINITY NUMANODE=0
La seguente query ritorna (20) dato che utilizzeremo solo 20 CPU logiche:
select COUNT(*) from sys.dm_os_schedulers where status = 'VISIBLE ONLINE'
2) Utilizzo del primo (ed unico) NUMA nel “Processor Group” [0] e del primo NUMA node del secondo “Processor Group”:
ALTER SERVER CONFIGURATION SET PROCESS AFFINITY NUMANODE=0,1
La seguente query ritorna (40) dato che utilizzeremo 40 CPU logiche:
3) Utilizzo di tutti i NUMA node in entrambi i “Processor Group” (il default !):
ALTER SERVER CONFIGURATION SET PROCESS AFFINITY CPU = AUTO
La seguente query ritorna (80) dato che utilizzeremo tutte le 80 CPU logiche:
4) Utilizzo delle 20 CPU logiche del primo nodo NUMA e delle 20 del quarto nodo NUMA, tutte nel secondo “Processor Group” (PG[1]):
ALTER SERVER CONFIGURATION SET PROCESS AFFINITY CPU = 0 TO 19, 60 TO 79;
La seguente query ritorna (40):
Con questi esempi spero che la trattazione dell’argomento sia completa, prima di lasciarVi però vorrei ribadire un ultimo importante concetto: oltre al supporto da parte del Sistema Operativo, anche l’applicazione/servizio deve essere capace di supportare un numero massimo di CPU logiche oltre le 64, altrimenti quello che succede è che a tale servizio/applicazione verrà assegnato un singolo “Processor Group” , con un massimo di 64 CPU logiche, ed ovviamente non sarà in grado di utilizzare le altre unità disponibili.
Mi è stato più volte chiesto se fosse supportata da Microsoft la combinazione di SQL Server Clustering e Database Mirroring.
Prima di tutto è utile fare un passo indietro, e chiedersi quali siano gli scenari in cui questo mix possa risultare utile.
SQL Server Clusterizzato lavora a livello di istanza, e forisce una soluzione di High Availability che permette al servizio di SQL Server (e a tutte le risorse da cui esso dipende) di realizzare un failover su un’altro sistema (fisico o virtuale) a fronte di un guasto Hardware o Software. La sola implementazione del Clustering non copre scenari di Disk Failure, o più in generale di perdita o corruzione di file di database (data o log), o di Disaster Recovery.
Se da un lato è possibile ricorrere a soluzioni di Data Replication fornite dai vendor SAN, a partire da SQL Server 2005 SP1 è possibile utilizzare il Database Mirroring per “replicare” i file di dei soli database utente su una seconda istanza presente sul notro sito di DR, rilasciando quindi la completa gestione dell’attività di “copia” a SQL Server. Implementando il failover automatico del database mirroring (modalità High Availability con Witness), è possibile fare in modo che, a fronte di un guasto sul sito principale, i nostri database si ritrovino in automatico pronti per l’uso sul sito di DR.
Tutto perfetto. A meno di errori architetturali e/o di configurazione.
1) E’ sempre bene ricordare che il Database Mirroring lavora a livello di Database, e non di Istanza. Quindi:
2) Immaginiamoci il seguente scenario.
Cluster a due nodi con singola istanza SQL sul sito principale, Mirror in DR (clusterizzato o standalone, poco importa). Abbiamo un guasto hardware sul primo nodo, dove la nostra istanza SQL Server era attiva. Cosa vorremmo che accadesse? Sicuramente vorremmo mantenere il servizio attivo sul sito principale, e quindi vorremmo che in automatico venisse eseguito un failover dal primo al secondo nodo. Peccato che, se non interveniamo modificando il comportamento del mirroring, di default ci ritroveremmo operativi sul nodo DR. Questo perchè il failover del Mirroring è molto più veloce del Failover del Clustering.
Nel mirroring viene inviato un messaggio di “ping” ogni secondo, e in caso di mancata risposta viene eseguito il failover dopo 10 secondi. Nel caso del clustering, un failover impiega circa 60-90 secondi (più tempi vari di analysis,redo(rolll forward) e undo(roll back) con quest’ultima non incidente nei tempi di fail-over in caso di enterprise edition(Fast Recovery) e di inizializzazione dei file del temdb – a mano che non sia stato implementata l’instant file initialization valida solo per i file dati non per i log).
A fronte di un semplice failover del cluster, quindi, il witness non vede i database “mirrorati” per 10 secondi, e di conseguenza scatena un failover su DR.
E’ bene quindi, nel caso di implementazione del Mirroring con Cluster, modificare questo tempo di failover di default, e aumentarlo, ad almeno 90 secondi:
ALTER
DATABASE nomedatabase SET PARTNER TIMEOUT 90;
GO
3) Immaginiamoci di avere un sito principale, diciamo a Segrate, che contiene il nostro Cluster e il nostro Witness. Un sito di DR a Roma.
Immaginiamoci che l’intero nostro sito principale non risulti più disponibile. Cosa vorremmo che accadesse? Probabilmente che tutti i nostri database effettuassero un failover sull’istanza di Roma. Cosa accadrebbe invece? Nulla. Nessun failover. Senza il witness (che, trovandosi nella sede pricipale, è fuori uso a sua volta), perdiamo la possibilità di failover automatico. E’ quindi bene “posizionare” il notro witness in un sito che sia strategico rispetto agli scenari che vorremmo poter gestire, e quindi anche rispetto alla perdita di un sito intero. La soluzione migliore sarebbe quella di avere un terzo sito.
Per ricapitolare.
Microsoft supporta la convivenza di SQL Server Mirroring e Clustering.
Nel progettarne l'architettura però, è sempre bene verificare che tutti i possibili scenari di failure siano stati rivisti e testati, e che le configurazioni siano state adattate per poter ottenere il comportamento desiderato.
E’ una domanda, assolutamente non provocatoria, che ho ricevuto di recente da alcuni Clienti preoccupati dall’impossibilità di sfruttare a pieno il non trascurabile investimento in un hardware di ultima generazione, magari server dotati delle recenti CPU “Westmere” di Intel con ben 10 Core per CPU. Ovviamente, nel contesto di questo articolo faremo implicito riferimento alle sole architetture “x64”, considerando anche i processori forniti da AMD, oltre che a quelli di INTEL.
Accanto a questa domanda, eccone un'altra che da un po’ di anni non sentivo, e cioè: “E’ consigliato disabilitare l’Hyper Threading ?” Nonostante esistano moltissimi articoli e altro materiale su Internet che dibattono sull’argomento, un punto fermo non esiste e la prima banale risposta a questa seconda domanda è la più odiosa che spesso mi sento rivolgere da inglesi e americani: “It depends !” J . Prometto che in prossimo “post” cercherò di chiarire questo famoso punto certo.
In questo caso la domanda è più pertinente del solito perché nel caso di un server con 4 CPU, ognuna con 10 CORE e dotate di Hyper Threading, il numero di CPU “logiche” disponibili per SQL Server (e Windows) arrivano ad un totale di (4 x 10 x 2) = 80 !
L’idea, non completamente corretta, del mio Cliente era di disabilitare l’Hyper Threading per abbassare il numero di CPU “logiche” da 80 a 40 in modo da rientrare nel limite delle 64 CPU logiche tanto, come è convinzione diffusa, (1) più di 64 non sono sono gestite e (2) l’Hyper Threading non dà alcun vantaggio in SQL Server.
Per quanto riguarda il primo punto relativo all’ Hyper Threading, mi spiace ma dovrete aspettare un successivo post, qui mi limito a riportare due semplici considerazioni basata su un discreto numero di anni di esperienza sul campo in questo settore:
Ora veniamo al punto principale della questione e quindi al soggetto di questo articolo, e cioè il discorso relativo al numero massimo di CPU/CORE: SQL Server 2008 supporta più di 64 CPU “logiche” ? In che condizioni ? Su quali versioni ?
NOTA per l’autore: ricordare a Microsoft di riportare in queste tabelle anche l’informazione relativa ai CORE e alle CPU “logiche” onde evitare ulteriore confusione da parte dei Clienti;
Quindi, ricapitolando, con Windows Server 2008 R2 e SQL Server 2008 R2 è possibile arrivare a sfruttare a pieno fino ad un totale di 256 CPU “logiche”, inteso come numero ottenuto moltiplicando il numero di “SOCKET” al numero di “CORE” per ogni “SOCKET”, infine moltiplicando il tutto per due in caso di Hyper Threading, ad esempio:
IMPORTANTE: In particolare riferimento all’ultima ipotesi numerica sopra riportata, e considerato l’annuncio sia da parte di INTEL che di AMD di nuove CPU con ancora maggiori numeri di “CORE”, è altamente probabile, ma non sicuro/ufficiale, che il numero massimo di CPU “logiche” attualmente supportato sia innalzato prima dell’uscita della prossima versione “Server” di “Windows”, presumibilmente con il rilascio di una nuova “Service Pack”.
Ci sono alcune considerazioni aggiuntive che, in questi scenari da più di 64 CPU “logiche”, devono essere fatte:
Process name
Use more than 64 CPUs
SQL Server Database Engine
Yes
Reporting Services
No
Analysis Services
Integration Services
Service Broker
Full-Text Search
SQL Server Agent
SQL Server Management Studio
SQL Server Setup
In un prossimo post proverò ad addentrarmi nei meccanismi di SQL Server che riguardano le architetture NUMA, il famigerato parametro MAXDOP, le relative ottimizzazioni ed ai problemi che ne possono scaturire.
-Igor Pagliai-
Questo blog è dedicato a chi lavora con Microsoft SQL Server ed è pensato per condividere Best Practices, Informazioni Utili e soprattutto Esperienze acquisite sul campo (e difficilmente ritrovabili in libri, manuali o... veloci ricerche su internet) da parte del nostro team: l’Italian Premier Center for SQL Server.
Il nostro gruppo, parte di Microsoft Italia, lavora a stretto contatto con i clienti Premier che si occupano (direttamente o non) di SQL Server, erogando workshop, chalk and talks, review architetturali e supportando le attività di performance tuning e troubleshooting delle implementazioni più importanti.
Starring: