Max grado di parallelismo (DOP) è un'opzione di configurazione avanzata di SQL Server che è stata oggetto di molte domande ed è stata oggetto di molte pubblicazioni. In questo post sul blog, l'autore spera di fornire un po' di chiarezza su cosa fa questa opzione e come dovrebbe essere utilizzata.

In primo luogo, l'autore vorrebbe dissipare qualsiasi dubbio sul fatto che l'opzione precedente imposta quanti processori SQL Server può utilizzare quando serve più connessioni (o utenti), ma non è così! Se SQL Server ha accesso a quattro processori inattivi ed è configurato per utilizzare tutti e quattro i processori, utilizzerà tutti e quattro i processori indipendentemente dal grado massimo di parallelismo.

Quindi cosa fa questa opzione? Questa opzione imposta il numero massimo di processori che SQL Server può utilizzare per una singola query. Se deve restituire una query a SQL Server grande volume data (molti record), a volte ha senso parallelizzarlo suddividendolo in diverse piccole query, ognuna delle quali restituirà il proprio sottoinsieme di righe. Quindi SQL Server può utilizzare più processori e quindi su sistemi multiprocessore un gran numero di i record dell'intera query potrebbero essere restituiti più rapidamente rispetto a un sistema monoprocessore.

Esistono molti criteri che devono essere considerati prima che SQL Server richiami "Intra Query Parallelism" (distribuzione di una query in più thread) e non ha senso descriverli in dettaglio qui. Puoi trovarli in BOL cercando "Grado di parallelismo". Dice che la decisione sulla parallelizzazione si basa sulla disponibilità di memoria per il processore e, soprattutto, sulla disponibilità dei processori stessi.

Pertanto, il motivo per cui dovremmo considerare l'utilizzo di questa opzione è perché lasciarlo al valore predefinito (SQL Server decide sulla parallelizzazione stessa) a volte può avere effetti indesiderati. Questi effetti sono simili a questo:

• Le query parallele vengono eseguite più lentamente.
• I tempi di esecuzione delle query possono diventare non deterministici e questo può infastidire gli utenti. Il tempo di esecuzione può variare perché:
  • Una query a volte può essere parallelizzata ea volte no.
  • Una richiesta può essere bloccata da una richiesta parallela se i processori sono stati precedentemente sovraccaricati di lavoro.

Prima di continuare, l'autore fa notare che non c'è bisogno di approfondire l'organizzazione interna del parallelismo. Se sei interessato a questo, puoi leggere l'articolo "Elaborazione di query parallele" in Books on Line, dove queste informazioni sono presentate in modo più dettagliato. L'autore ritiene che ci siano solo due cose importanti da sapere sull'organizzazione interna del parallelismo:

1. Le richieste parallele possono generare più thread di quelli specificati nell'opzione "Massimo grado di parallelismo". DOP 4 può generare più di dodici thread, quattro per query e thread aggiuntivi utilizzati per ordinamenti, thread, aggregati e assiemi e così via.
2. Il parallelismo delle query può causare diverse attese SPID con un tipo di attesa CXPACKET o 0X0200. Questo può essere utilizzato per trovare quegli SPID che sono in attesa di operazioni parallele e hanno waittype: CXPACKET in sysprocesses. Per facilitare questo compito, l'autore suggerisce di utilizzare la procedura memorizzata disponibile nel suo blog: track_waitstats.

E quindi "La query potrebbe essere più lenta se parallela" perché?

• Se il sistema è molto debole portata sottosistemi del disco, quindi durante l'analisi di una query, la sua scomposizione può richiedere più tempo che senza parallelismo.
• Possibili blocchi dei dati o dell'intervallo di dati per il processore, generati da un altro processo utilizzato in parallelo e avviato in seguito, ecc.
• Se non è presente alcun indice per il predicato, viene eseguita una scansione della tabella. Un'operazione parallela all'interno di una query può nascondere il fatto che la query verrebbe eseguita molto più velocemente con un piano di esecuzione sequenziale e con l'indice corretto.

Gli effetti del parallelismo sopra menzionati dovrebbero di per sé portare all'idea che la meccanica interna della parallelizzazione delle query non sia adatta per l'uso nelle applicazioni OLTP. Si tratta di applicazioni per le quali la modifica del tempo di esecuzione delle query può infastidire gli utenti e per le quali è improbabile che un server che serve più utenti contemporaneamente scelga un piano di esecuzione parallela a causa delle caratteristiche intrinseche del profilo del carico di lavoro del processore in queste applicazioni.

Pertanto, se hai intenzione di utilizzare il parallelismo, molto probabilmente sarà necessario per attività di estrazione dati (data warehouse), supporto alle decisioni o sistemi di reporting, dove non ci sono molte query, ma sono piuttosto pesanti e vengono eseguite su un potente server con una grande quantità di memoria operativa.

Se decidi di utilizzare il parallelismo, quale valore dovresti impostare per DOP?. È buona norma per questo meccanismo che, se si hanno 8 processori, impostare DOP = 4 ed è molto probabile che questa sia l'impostazione ottimale. Tuttavia, non vi è alcuna garanzia che funzionerà in questo modo. L'unico modo per esserne sicuri è testare valori diversi per DOP. Oltre a questo, l'autore ha voluto offrire il suo consiglio empirico, non impostare mai questo numero a più della metà del numero di processori disponibili. Se l'autore avesse meno di sei processori, imposterebbe DOP su 1, il che disabilita semplicemente la parallelizzazione. Potrebbe fare un'eccezione se avesse un database che supporta un solo processo utente (alcune tecnologie di recupero dati o attività di reporting), nel qual caso, come eccezione, sarebbe possibile impostare DOP su 0 (impostazione predefinita), che consente a SQL Server di decidere autonomamente se parallelizzare una query.

Prima di concludere l'articolo, l'autore ha voluto avvertirti che la creazione parallela degli indici dipende dal numero che hai impostato per DOP. Ciò significa che potresti volerlo modificare al momento della creazione o della ricreazione degli indici per migliorare le prestazioni di questa operazione, e ovviamente puoi utilizzare l'hint MAXDOP nella query, che ti consente di ignorare il valore impostato nella configurazione e può essere utilizzato durante le ore non di punta.

Infine, la tua richiesta potrebbe rallentare se parallelizzata a causa di errori, quindi assicurati di avere il service pack più recente installato sul tuo server.

REATE proc track_waitstats
@num_samples int = 10
,@numero di ritardo int = 1
,@delaytype nvarchar ( 10 )="minuti"
COME
-- T. Davidson
-- Questa procedura memorizzata viene fornita =COSÌ COM'È= senza garanzie,
-- e conferenze senza diritti.
-- L'uso degli esempi di script inclusi è soggetto ai termini
-- specificato in http://www.microsoft.com/info/cpyright.htm
-- @num_samples è il numero di volte per acquisire le statistiche di attesa,
-- il valore predefinito è 10 volte. l'intervallo di ritardo predefinito è 1 minuto
-- delaynum è l'intervallo di ritardo. delaytype specifica se
-- l'intervallo di ritardo è di minuti o secondi
-- crea la tabella waitstats se non esiste, altrimenti tronca

non contare
se non esiste (selezionare 1 da sysobjects dove name = "waitstats" )
crea tabelle waitstats(varchar( 80 ),
richieste numeriche ( 20 ,1 ),
numerico ( 20 ,1 ),
numerico ( 20 ,1 ),
ora datetime predefinito getdate())
altrimenti tronca le waitstats della tabella

dbcc sqlperf (waitstats, clear) -- cancella waitstats

dichiarare @i int
,@delay varchar ( 8 )
,@dt varchar ( 3 )
,@now data e ora
,@totalwait numerico ( 20 ,1 )
,@endtime dataora
,@inizio ora data ora
,@hr int
,@min int
,@sec int

seleziona @i = 1
seleziona @dt = minuscolo (@delaytype)
quando "minuti" poi "m"
quando "minuto" poi "m"
quando "min" poi "m"
quando "mm" poi "m"
quando "mi" poi "m"
quando "m" poi "m"
quando "secondi" poi "s"
quando "secondo" poi "s"
quando "sec" poi "s"
quando "ss" poi "s"
quando "s" poi "s"
altro @delaytype
fine

se @dt non in ("s" ,"m" )
inizio
Stampa "si prega di fornire il tipo di ritardo, ad esempio secondi o minuti"
Restituzione
fine

se @dt = "s"
inizio
seleziona @sec = @delaynum % 60
seleziona @min = cast((@delaynum / 60 ) come int )
seleziona @ora = cast((@min / 60 ) come int )
seleziona @min = @min % 60
fine

se @dt = "m"
inizio
seleziona @sec= 0
seleziona @min = @delaynum % 60
select @hr = cast((@delaynum / 60 ) come int )
fine

select @delay = right("0" + convert(varchar( 2 ),@h), 2 ) + ":" +
2 ),@min), 2 ) + ":" +
+ destra("0" +convert(varchar( 2 ),@sec), 2 )

se @hr > 23 o @min > 59 o @sec > 59
inizio
Selezionare "hh:mm:ss il tempo di ritardo non può essere > 23:59:59"
seleziona "intervallo di ritardo e digita: " + convert (varchar ( 10 )
,@delaynum) + "," + @delaytype + " converte in "
+ @ritardo
Restituzione
fine

mentre io<= @num_samples)
inizio
inserisci in waitstats(, request,
,)
exec("dbcc sqlperf(waitstats)" )
seleziona @i = @i + 1
waitfor delay @delay
Fine

Crea rapporto waitstat
esegui get_waitstats

--//--//--//--//--//--//--//--//--//-//--//--//--//--//--//--//--//--/

CREA proc get_waitstats
COME
-- Questa procedura memorizzata viene fornita =COSÌ COM'È= senza garanzie e
-- conferenze senza diritti.
-- L'uso degli esempi di script inclusi è soggetto ai termini specificati
-- su http://www.microsoft.com/info/cpyright.htm
--
-- questo processo creerà un rapporto waitstats elencando i tipi di attesa per
-- percentuale
-- può essere eseguito quando track_waitstats è in esecuzione

non contare

dichiara @now datetime
,@totalwait numerico ( 20 ,1 )
,@endtime dataora
,@inizio ora data ora
,@hr int
,@min int
,@sec int

seleziona @now=max (ora),@begintime=min (ora),@endtime=max (ora)
da waitstats dove = "Totale"

Sottrai waitfor, sleep e resource_queue da Total

seleziona @totalwait = somma() + 1 da waitstats
dove non in ("WAITFOR" ,"SLEEP" ,"RESOURCE_QUEUE"
, "Totale" , "***totale***" ) e ora = @ora

Inserisci i totali rettificati, classifica per percentuale decrescente

elimina waitstats where = "***total***" e now = @now

inserisci in waitstats seleziona "***total***"
,0
,@totalwait
,@totalwait
,@adesso

Selezionare
,
,percentuale = cast ( 100 */@totalwait come numerico ( 20 ,1 ))
da waitstats
dove non in ("WAITFOR" ,"SLEEP" ,"RESOURCE_QUEUE" ,"Total" )
e ora = @ora
ordina per percentuale disc

In questa breve nota, vorrei parlare un po' della complessità delle impostazioni di concorrenza in Microsoft SQL Server. Molti di voi conoscono da tempo l'opzione Max Degree od Parallelism, presente in SQL Server da molto tempo. Per impostazione predefinita, è impostato su 0, il che significa che SQL Server sceglierà il grado ottimale di parallelismo stesso, ovvero il numero di processori/thread coinvolti nell'esecuzione di un'istruzione. Non mi fermerò ora e discuterò su quale valore è meglio impostare questa opzione: questo è un argomento per una nota separata. Considererò solo come il valore di questa opzione influisce sull'esecuzione delle query. Ad esempio, nella figura seguente, questa opzione è impostata su 1, il che significa che i piani paralleli per tutte le query sono disabilitati per impostazione predefinita.

Questa opzione è disponibile anche per la visualizzazione con il seguente comando T-SQL:

In effetti, qualsiasi piano di query predefinito sarà sequenziale. Per esempio:

Tuttavia, lo sviluppatore e qualsiasi utente hanno ancora l'opportunità di influenzare questo attraverso l'uso di suggerimenti. Per fare ciò, è sufficiente specificare il grado di parallelismo desiderato e viene generato il piano di query desiderato, ad esempio:

E se osserviamo questa query attraverso la vista sys.dm_exec_query_profiles, vedremo che viene effettivamente eseguita in 10 thread.

Pertanto, rimane un buco segreto nel sistema che sviluppatori e utenti possono utilizzare per "accelerare" (qui lo metto specificamente tra virgolette, perché non sempre un grande grado di parallelismo porta a una diminuzione del tempo di esecuzione delle query) le loro query aumentando il grado di parallelismo. Ma, in questo modo, possono semplicemente "uccidere" il server lanciando molte richieste parallele non controllate contemporaneamente. Cosa possiamo fare al riguardo? È qui che viene in soccorso Resource Governor, un sistema molto potente e completamente sottovalutato che consente di distribuire in modo molto flessibile le risorse tra diversi gruppi di utenti. Ancora una volta, non mi soffermerò su come funziona e quali capacità ha. Mi limiterò a spiegare in che modo le sue impostazioni del limite di concorrenza lo influenzano. Diamo prima un'occhiata alle impostazioni predefinite:

Ancora una volta, vediamo che l'opzione è impostata su 0 per impostazione predefinita e la decisione di scegliere il grado massimo è alla mercé di SQL Server. Ora vediamo cosa succede se cambio questo valore in 5. Non ho nemmeno definito una funzione di classificazione per Resource Governor e sto modificando il gruppo predefinito. Ma per un test e per capire come funziona tutto in questo momento nel mio esempio, questo è sufficiente. Pertanto, limito il massimo grado di parallelismo per tutti a 5 thread. Ricordiamo che l'opzione Massimo grado di parallelismo, che abbiamo visto in precedenza, è ancora impostato su 1. Se ora osserviamo il piano di esecuzione della nostra query originale, per impostazione predefinita sarà sequenziale e, con l'opzione maxdop 10, sarà parallela. Ma, se eseguiamo un piano parallelo, vedremo qualcosa di interessante.

Ora la nostra richiesta viene eseguita solo in 5 thread, nonostante l'opzione max ha un valore di 10. E, se si specifica l'opzione maxdop 4 per la query, verrà eseguita in 4 thread (l'opzione in Resource Governor è impostata su 5). In questo caso, il suggerimento max inferiore all'impostazione di Resource Governor, quindi non viene imposta alcuna restrizione aggiuntiva. Non faccio più un esempio di questo.

Pertanto, Resource Governor è uno strumento più potente che già limita davvero il massimo grado di parallelismo per le query e questo grado può essere impostato in modo diverso per diversi gruppi di utenti. Allo stesso tempo, l'opzione Massimo grado di parallelismo funziona ancora e fa la sua parte (o confonde leggermente amministratori, sviluppatori e utenti se abbinato a Resource Governor). Inoltre, le opzioni per impostare i valori di questi 2 parametri sono limitate solo dalla tua immaginazione, ma è importante ricordare solo due cose: Massimo grado di parallelismo e suggerimento max per una richiesta influisce sul piano che verrà generato, sul numero massimo di thread possibile per questa richiesta e Resource Governor limita ulteriormente la richiesta dall'alto già in fase di esecuzione.

Obbiettivo: studiare l'impatto del parallelismo SQL sull'utilizzo delle query 1C

Letteratura:

Ambiente di test:

Windows Server 2008 R2 Enterprise

MS SQL Server 2008 R2

1C Impresa 8.2.19.90

Figura 1. Proprietà SQL “Generale”

Figura 2. Proprietà SQL "Avanzate"

Strumenti:

Profilatore di server SQL

Console delle query 1C

Richiesta di prova:

SCEGLIERE

AK.Nome AS Nome

DA

Registro delle informazioni Classificatore di indirizzi AS AK

UNIONE INTERNA Registro delle informazioni Classificatore di indirizzi AS AK1

SW AK.Code = AK1.Code

Addestramento:

Avviamo SQL Server Profiler, stabiliamo una connessione, contrassegniamo eventi e colonne come mostrato nella Figura 3.

Figura 3. Proprietà di traccia

Impostazione della selezione per la nostra base

Figura 4. Filtra per database

Abbreviazioni:

Massimo grado di parallelismo - MDOP

Soglia di costo per il parallelismo - costo

Test di un piano di query sequenziale (MDOP = 1)

Figura 5. Console delle query: tempo di esecuzione di 20 secondi

Il parametro del server SQL "Max grado di parallelismo" è impostato su 1 (nessun parallelismo). Osserviamo il risultato nel profiler (Fig. 6)

Figura 6. Piano di query sequenziale

Il server SQL ha generato un piano di query sequenziale, mentre: carico totale della CPU = 6,750 (sec) e tempo di esecuzione della query = 7,097 (sec)

Test del piano di query in parallelo (MDOP = 0, costo =5)

Mettiamo il server SQL in modalità parallelismo (in SQL Query):

USA master ;

EXEC sp_configure "mostra opzione avanzata" , 1;

RICONFIGURA CON OVERRIDE

USA master ;

exec sp_configure "max grado di parallelismo" , 0;

RICONFIGURA CON OVERRIDE

Esecuzione della stessa query (Figura 7)

Figura 7. Console delle query: tempo di esecuzione di 16 secondi

Verifica del risultato nel profiler (Figura 8)

Figura 8. Piano di query parallele

Il server SQL questa volta ha formato un piano di query parallelo, con il carico totale della CPU = 7,905 secondi e la durata della query = 3,458 secondi

Test di un piano di query sequenziale (MDOP = 0, costo = 150)

Proviamo a sbarazzarci del piano parallelo utilizzando il parametro "Soglia di costo per parallelismo". Per impostazione predefinita, il parametro è impostato su 5. Nel nostro caso, siamo riusciti a eliminare la formazione di un piano parallelo con un valore di 150 (in SQL Query):

USA master ;

exec sp_configure "soglia di costo per il parallelismo", 150 ;

Verifichiamo l'esecuzione della richiesta in queste condizioni (Fig. 9)

Figura 9. Console delle query: tempo di esecuzione di 20 secondi

Controlliamo il risultato nel profiler (Fig. 10)

Figura 10. Piano di query sequenziale.

SQL Server ha generato un piano di query sequenziale. Utilizzo totale della CPU = 7,171 sec, tempo di esecuzione della query = 7,864 sec.

Conclusioni:

L'esecuzione di una query di test nell'ambiente 1C Enterprise utilizzando un piano di query parallela del server SQL offre un aumento significativo delle prestazioni rispetto a un piano sequenziale (16 sec. vs. 20 sec. - guadagno 4 sec.)

L'esecuzione della query di test da parte di SQL Server stesso quando si utilizza un piano di query parallelo è due volte più veloce rispetto a quando si utilizza un piano di query seriale (3,5 secondi contro 7,1 secondi)

Il parallelismo del server SQL può essere regolato non solo utilizzando il parametro MDOP, ma anche il parametro "Soglia ost per il parallelismo"

• tutorial

Questa guida è destinata ai principianti che cercano una semplice guida in russo per installare la versione inglese di SQL Server 2012, che verrà utilizzata per SharePoint 2013.
Questo articolo non è per professionisti.

Tutto il lavoro è suddiviso in 3 fasi:

• Installazione di SQL Server 2012
• Impostazione dell'opzione di configurazione del server del massimo grado di parallelismo
• Configurazione dei diritti dell'account destinato all'installazione di SharePoint 2013

L'articolo descrive anche il processo di installazione di Microsoft .NET Framework 3.5 su MS Windows Server 2012 R2 Standard.

Attenzione: ci sono molte foto sotto il taglio!

Installazione di SQL Server 2012

1. Prima dell'installazione, dovresti assicurarti che ci sia abbastanza spazio libero sul tuo disco rigido (nel mio caso, ci sono voluti 2,7 GB).
Dopo aver avviato il kit di distribuzione, seleziona la voce " Installazione" nel menu a sinistra, quindi "clicca" sulla voce " Nuovo SQL Server autonomo o aggiungi funzionalità a un'installazione esistente":

2. Verrà avviata la procedura guidata di installazione. Controllerà. È possibile fare clic sul pulsante "Mostra dettagli" e visualizzare un rapporto dettagliato:

3. Rapporto dettagliato. Premi il pulsante "OK":

4. Immettere la chiave del prodotto e fare clic sul pulsante "Avanti":

5. Siamo d'accordo con i termini del contratto di licenza.
Per fare ciò, seleziona la casella accetto i termini della licenza

6. Nella fase "Imposta ruolo", seleziona la prima voce " Installazione della funzionalità di SQL Server". Premi il pulsante "Avanti":

7. Nel passaggio "Selezione delle funzioni", seleziona " Servizi del motore di database", "Strumenti di gestione di base" e " Strumenti di gestione - Completa". Quindi fare clic sul pulsante "Avanti":

8. Il programma di installazione eseguirà quindi un altro controllo. È possibile fare clic sul pulsante "Mostra dettagli" e visualizzare un rapporto dettagliato:

9. Rapporto dettagliato. (In questa fase, ho ricevuto un errore nella regola "Microsoft .NET Framework 3.5 è installato ...". Maggiori informazioni di seguito). Premi il pulsante "Avanti":

10. Nel passaggio "Configurazione istanza", è necessario configurare l'istanza del servizio SQL Server.
Ancora una volta, questo articolo è per principianti. Pertanto, assumeremo che SQL Server non sia stato installato prima sul tuo server, il che significa che lasceremo tutte le impostazioni predefinite. Premi il pulsante "Avanti":

11. In questo passaggio, l'installazione guidata visualizzerà i requisiti di spazio su disco. Premi il pulsante "Avanti":

12. Al passaggio "Configurazione del server", è necessario specificare un account di dominio per il servizio " Motore di database di SQL Server". Dopo aver compilato i campi "Nome account" e "Password", fare clic sul pulsante "Avanti":

13. Al passaggio "Configurazione del motore di database", è sufficiente aggiungere l'utente corrente agli amministratori del server SQL. Per fare ciò, fai clic sul pulsante "Aggiungi utente corrente", quindi fai clic sul pulsante "Avanti":

14. Al passaggio successivo, fare clic sul pulsante "Avanti":

15. Successivamente, la procedura guidata di installazione eseguirà nuovamente il test e ne visualizzerà i risultati. Premi il pulsante "Avanti":

16. Al passaggio "Pronto per l'installazione", la procedura guidata visualizzerà informazioni di riepilogo. Qui è necessario fare clic sul pulsante "Installa":

17. Al termine dell'installazione, verranno visualizzate le informazioni sulle operazioni eseguite:

18. Consiglio vivamente di riavviare il computer in questa fase. In alcuni casi (ad esempio, durante l'installazione di Microsoft .NET Framework 3.5), l'installazione guidata stessa visualizzerà una finestra che richiede di riavviare il computer. Non mollare.

Impostazione dell'opzione di configurazione del server del massimo grado di parallelismo

Il valore predefinito per il parametro "Massimo grado di parallelismo" è 0.
SharePoint 2013 richiede che questa impostazione sia 1.
È facile da risolvere!

1. Corri Studio di gestione di Microsoft SQL Server(Start - Tutti i programmi - Microsoft SQL Server 2012 - SQL Server Management Studio).

2. Nella schermata di connessione al server, fare clic sul pulsante Connetti.

3. Fai clic con il pulsante destro del mouse sul tuo server nella sezione " Esplora oggetti" e seleziona " Proprietà":

4. Nella finestra delle proprietà del server che si apre, nel menu di sinistra, selezionare la pagina " Avanzate" e scorrere l'elenco delle proprietà fino in fondo allo schermo. Impostare il valore del parametro " Massimo grado di parallelismo" in 1 e fare clic sul pulsante "OK":

5. Non chiudere SQL Server Management Studio, ne avremo ancora bisogno.

Configurazione dei diritti dell'account destinato all'installazione di SharePoint 2013

L'account con cui verrà installato SharePoint 2013 deve essere elevato in SQL Server.
Si consiglia di assegnare a questo account i seguenti ruoli:

• dbcreatore
• amministratore della sicurezza
• pubblico

1. In SQL Server Management Studio, nella sezione " Esplora oggetti"Espandi elemento" Sicurezza". Quindi fare clic con il pulsante destro del mouse su " Accesso" e seleziona " Nuovo accesso":

2. Nel campo "Nome di accesso", immettere il nome di dominio dell'account con cui si prevede di installare e configurare SharePoint 2013.

3. Nel menu a sinistra, seleziona la pagina " Ruoli del server" e controlla i ruoli "dbcreator" e "securityadmin" e assicurati che il ruolo "pubblico" sia già selezionato. Quindi fai clic sul pulsante "OK":

SQL Server è ora pronto per installare SharePoint 2013.

Installazione di Microsoft .NET Framework 3.5 su MS Windows Server 2012 R2 Standard

Al punto 9 del paragrafo " Installazione di SQL Server 2012" Ho ricevuto un errore: .NET Framework 3.5 non è stato installato.
Per risolvere questo problema, attenersi alla seguente procedura:

1. Devi aprire la console " gestore del server".

2. Nel menu a sinistra, seleziona la voce "Dashboard".

3. Al centro della finestra, fare clic sulla voce "Aggiungi ruoli e funzionalità".

4. Nella procedura guidata che si apre, salta il passaggio "Prima di iniziare".

5. Al passaggio "Tipo di installazione", selezionare " Installazione basata su ruoli o basata su funzionalità". Premere il pulsante "Avanti".

6. Nel passaggio successivo, lascia tutto come predefinito e fai clic sul pulsante "Avanti".

7. Salta il passaggio "Ruoli del server" facendo clic sul pulsante "Avanti".

8. Al passaggio "Caratteristiche", selezionare la casella di controllo "Caratteristiche di .NET Framework 3.5". Premiamo il pulsante "Avanti".

9. Al termine del processo di installazione, è possibile chiudere l'Aggiunta guidata ruoli e funzionalità.

10. Fatto!

Tutto buono e sereno cielo sopra la tua testa!

PS Buona Giornata della Cosmonautica!

Questo post si concentrerà solo su MS SQL Server. Se hai intenzione di "tentare la fortuna" nell'utilizzo di 1C con Oracle, DB2, Postrgre, queste informazioni saranno inutili per te. Ma devi capire che in 1C ci sono, prima di tutto, specialisti in MS SQL Server. Grazie agli sforzi di IBM, ci sono anche specialisti DB2. Puoi parlare a lungo di DBMS buono o cattivo, una cosa è importante, l'1C più "liscio" funziona con il server MS SQL. A giudicare dagli ultimi messaggi dal "front", il lavoro con DB2 è diventato più o meno decente. Sebbene personalmente abbia avuto l'esperienza di configurare 1C per funzionare con DB2 nella versione 8.1, in qualche modo non tutto era molto buono lì. In ogni caso, la scelta di un altro DBMS dovrebbe essere chiaramente argomentata - o dalle possibilità che non sono in MS SQL (un cluster con bilanciamento del carico, Grid, ecc.), o dalle finanze (Oracle è già stato acquistato), o da la piattaforma (tutto è su linux).

Quindi, in ordine, cosa è necessario fare con MS SQL Server:

1) Impostare la memoria minima e massima. Il minimo è metà della memoria di sistema. Massimo: memoria di sistema senza 2 GB. Questo viene fatto tramite Management Studio - nelle proprietà del server:

2) Se la priorità non è impostata nella scheda "Processori", è necessario impostarla

3) Impostare il massimo grado di parallelismo a 1.

4) Attiva SQL Server Agent, imposta Database Mail: non c'è niente di difficile lì, non descriverò in dettaglio.

5) Impostare i piani di servizio:
Generale:
a) Aggiornamento statistiche - ogni 2 ore
b) DBCC FREEPROCCACHE - ogni 2 ore
Per ogni base:
a) Backup completo
b) Backup differenziale
c) Deframmentazione dell'indice - ogni giorno
d) Ricostruzione dell'indice - notti di fine settimana
e) Verifica dell'integrità del database - una volta al mese di notte nei fine settimana

6) Consiglio di impostare il modello di ripristino come Semplice per ogni database (nelle proprietà). Se non hai un sistema 24 ore su 24, 7 giorni su 7 e meno di 1000 utenti per database, non esiste un cluster di failover e non hai firmato uno SLA in cui ti impegni a ripristinare i dati al secondo più vicino in caso di guasto di qualsiasi apparecchiatura (e non dal momento dell'ultimo backup) questa raccomandazione sarebbe ragionevole. Altrimenti, molto presto penserai a lungo e freneticamente a dove mettere il registro di tranzazione troppo cresciuto

7) Rimuovere il database tempdb dai database normali su un altro disco, anche se ciò significa riconfigurare l'array RAID e degradarne le prestazioni. In caso contrario, 1 utente potrà paralizzare il lavoro di tutti gli altri. Se hai un acceleratore hardware invece di un disco rigido, ovviamente non puoi separare e inserire tempdb su di esso, ma questo è solo se ce n'è uno

8) installa uno strumento di monitoraggio: mi piace Spotlight http://www.quest.com/spotlight-on-sql-server-enterprise/ per esempio

9) Mettiti alla prova con l'analizzatore di best practice di Microsoft - http://www.microsoft.com/download/en/details.aspx?id=15289 - un ottimo strumento che aiuta non solo con le impostazioni, ma anche con la risoluzione di molti problemi.

Ora, in poche parole, per cosa abbiamo fatto tutto questo:

1) Memoria. Il valore minimo ti salverà semplicemente da "glitch" quando il server SQL, per qualche motivo noto solo a lui, non utilizza tutta la memoria a sua disposizione. Devo mangiarlo tutto! Il valore massimo ti salverà dallo scambio se lo stesso ottimizzatore di utilizzo della memoria del server SQL decide che non danneggerebbe ....

3) Un punto molto importante: IHMO deve essere impostato su 1 in tutti i sistemi transazionali. In primo luogo, impedisce alcuni dei blocchi tra diversi processi che tentano di eseguire 1 richiesta e di conseguenza ci salva da alcuni "strani" errori. In secondo luogo... 1 richiesta "killing" sarà in grado di prendere il controllo di tutte le risorse del server, il che è alquanto ingiusto rispetto ad altri utenti del sistema. Il parametro stesso determina quanti core del processore possono elaborare 1 richiesta.

5) Informazioni sulle statistiche e sulla cancellazione della cache procedurale: questo è "a orecchio" ma spesso dimentichiamo la reindicizzazione. Nel frattempo, questa procedura è abbastanza importante, soprattutto con l'aumento del volume del database, la sua importanza aumenta. A volte fino al 60% delle prestazioni viene perso a causa della frammentazione dell'indice.

7) Se hai un Hardware Accelerator o solo 2 dischi con diverse velocità di accesso, ti consiglio anche di pensare all'allocazione di filegroup nei database e alla divisione delle singole tabelle in diversi array di dischi con diversi tempi di accesso. Dopotutto, sarai d'accordo sul fatto che il PH "merce nei magazzini" e il libro di riferimento "Conservazione di informazioni aggiuntive" sono 2 oggetti i cui requisiti per lo stoccaggio sono fondamentalmente diversi. Non è necessario archiviare tutti i file e le immagini nel database su un array veloce: puoi separarlo in uno separato, non così velocemente, ma dove c'è molto spazio (e non aver paura di caricare un mucchio di file nel database in seguito, tra l'altro).