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;
- Igor Pagliai -
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.
Buon lavoro a tutti !
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.
- Beatrice Nicolini -
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.
Buon lavoro a tutti.
-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:
Buona lettura!