Max Degree of Parallelism (DOP) ist eine erweiterte SQL Server-Konfigurationsoption, die Gegenstand vieler Fragen und Gegenstand vieler Veröffentlichungen war. In diesem Blogbeitrag hofft der Autor, etwas Klarheit darüber zu schaffen, was diese Option tut und wie sie verwendet werden sollte.

Zunächst möchte der Autor alle Zweifel zerstreuen, dass die obige Option festlegt, wie viele Prozessoren SQL Server verwenden kann, wenn mehrere Verbindungen (oder Benutzer) bedient werden – das tut es nicht! Wenn SQL Server Zugriff auf vier Prozessoren im Leerlauf hat und für die Verwendung aller vier Prozessoren konfiguriert ist, verwendet es alle vier Prozessoren unabhängig vom maximalen Parallelitätsgrad.

Was macht diese Option also? Diese Option legt die maximale Anzahl von Prozessoren fest, die SQL Server für eine einzelne Abfrage verwenden kann. Wenn eine Abfrage an SQL Server zurückgegeben werden soll großes Volumen Daten (viele Datensätze), ist es manchmal sinnvoll, sie zu parallelisieren, indem sie in mehrere kleine Abfragen aufgeteilt werden, von denen jede ihre eigene Teilmenge von Zeilen zurückgibt. So kann SQL Server mehrere Prozessoren und damit Multiprozessorsysteme verwenden große Menge Datensätze der gesamten Abfrage könnten möglicherweise schneller zurückgegeben werden als auf einem Einprozessorsystem.

Es gibt viele Kriterien, die berücksichtigt werden müssen, bevor SQL Server „Intra Query Parallelism“ (Abfrageaufteilung in mehrere Threads) aufruft, und es hat keinen Sinn, sie hier im Detail zu beschreiben. Sie finden sie in BOL, indem Sie nach „Parallelitätsgrad“ suchen. Es besagt, dass die Entscheidung zur Parallelisierung auf der Verfügbarkeit von Speicher für den Prozessor und insbesondere auf der Verfügbarkeit der Prozessoren selbst basiert.

Wir sollten also die Verwendung dieser Option in Betracht ziehen, weil das Belassen auf dem Standardwert (SQL Server beschließt, sich selbst zu parallelisieren) manchmal unerwünschte Auswirkungen haben kann. Diese Effekte sehen so aus:

• Parallelisierte Abfragen werden langsamer ausgeführt.
• Die Ausführungszeiten von Abfragen können nicht deterministisch werden, was Benutzer verärgern kann. Die Ausführungszeit kann sich ändern, weil:
  • Eine Abfrage kann manchmal parallelisiert werden und manchmal nicht.
  • Eine Anfrage kann durch eine parallele Anfrage blockiert werden, wenn die Prozessoren zuvor mit Arbeit überlastet waren.

Bevor wir fortfahren, möchte der Autor anmerken, dass es nicht notwendig ist, in die interne Organisation der Parallelität einzutauchen. Wenn Sie daran interessiert sind, können Sie den Artikel "Parallel Query Processing" in Books on Line lesen, wo diese Informationen ausführlicher dargestellt werden. Der Autor glaubt, dass es nur zwei wichtige Dinge gibt, die man über die interne Organisation der Parallelität wissen sollte:

1. Parallele Anfragen können mehr Threads hervorbringen, als in der Option "Max. Grad an Parallelität" angegeben. DOP 4 kann mehr als zwölf Threads hervorbringen, vier für Abfragen und zusätzliche Threads, die für Sortierungen, Threads, Aggregate und Assemblierungen usw. verwendet werden.
2. Abfrageparallelität kann unterschiedliche SPID-Wartezeiten mit einem Wartetyp von CXPACKET oder 0X0200 verursachen. Dies kann verwendet werden, um die SPIDs zu finden, die auf parallele Operationen warten und den Wartetyp: CXPACKET in sysprocesses haben. Um diese Aufgabe zu erleichtern, schlägt der Autor vor, die gespeicherte Prozedur zu verwenden, die in seinem Blog verfügbar ist: track_waitstats.

Und warum "Abfrage läuft möglicherweise langsamer, wenn sie parallelisiert wird"?

• Wenn das System sehr schwach ist Durchsatz Disk-Subsysteme, dann kann die Zerlegung einer Abfrage beim Parsen länger dauern als ohne Parallelität.
• Mögliche Datenverzerrung oder Datenbereichssperren für den Prozessor, die von einem anderen Prozess erzeugt wurden, der parallel verwendet und später gestartet wurde usw.
• Wenn es keinen Index für das Prädikat gibt, was zu einem Tabellenscan führt. Parallelbetrieb innerhalb einer Abfrage kann darüber hinwegtäuschen, dass die Abfrage mit einem sequentiellen Ausführungsplan und mit dem richtigen Index viel schneller laufen würde.

Die oben erwähnten Auswirkungen der Parallelität sollten Sie auf den Gedanken bringen, dass die interne Mechanik der Abfrageparallelisierung nicht für die Verwendung in OLTP-Anwendungen geeignet ist. Dies sind Anwendungen, bei denen das Ändern der Anforderungsausführungszeit Benutzer verärgern kann und bei denen ein Server, der viele Benutzer gleichzeitig bedient, aufgrund der inhärenten Eigenschaften des Prozessorauslastungsprofils in diesen Anwendungen wahrscheinlich keinen parallelen Ausführungsplan wählen wird.

Wenn Sie Parallelität verwenden, benötigen Sie sie daher höchstwahrscheinlich für Datenextraktionsaufgaben (Data Warehouse), Entscheidungsunterstützungs- oder Berichtssysteme, bei denen es nicht viele Abfragen gibt, die jedoch ziemlich umfangreich sind und auf einer leistungsstarken Ebene ausgeführt werden Server mit viel Arbeitsspeicher.

Wenn Sie sich für Parallelität entscheiden, welchen Wert sollten Sie für DOP? festlegen. Für diesen Mechanismus empfiehlt es sich, bei 8 Prozessoren DOP = 4 einzustellen, was sehr wahrscheinlich die optimale Einstellung ist. Es gibt jedoch keine Garantie, dass es so funktioniert. Die einzige Möglichkeit, dies sicherzustellen, besteht darin, verschiedene Werte für DOP zu testen. Darüber hinaus wollte der Autor seinen empirischen Rat geben, diese Zahl niemals auf mehr als die Hälfte der verfügbaren Prozessoren einzustellen. Wenn der Autor weniger als sechs Prozessoren hätte, würde er DOP auf 1 setzen, was einfach die Parallelisierung deaktiviert. Es könnte eine Ausnahme machen, wenn es eine Datenbank hat, die nur einen einzelnen Benutzerprozess unterstützt (einige Datenabruftechnologien oder Berichterstellungsaufgaben). In diesem Fall wäre es ausnahmsweise möglich, DOP auf 0 (Standardeinstellung) zu setzen erlaubt SQL Server selbst zu entscheiden, ob eine Abfrage parallelisiert werden soll.

Bevor der Artikel endet, wollte der Autor Sie warnen, dass die parallele Erstellung von Indizes von der Anzahl abhängt, die Sie für DOP festlegen. Dies bedeutet, dass Sie es möglicherweise zum Zeitpunkt der Erstellung oder Neuerstellung von Indizes ändern möchten, um die Leistung dieser Operation zu verbessern, und natürlich können Sie den MAXDOP-Hinweis in der Abfrage verwenden, wodurch Sie den in der gesetzten Wert ignorieren können Konfiguration und kann außerhalb der Geschäftszeiten verwendet werden.

Schließlich kann sich Ihre Anfrage aufgrund von Fehlern verlangsamen, wenn sie parallelisiert wird. Stellen Sie daher sicher, dass Sie das neueste Service Pack auf Ihrem Server installiert haben.

REATE proc track_waitstats
@num_samples int = 10
,@delaynum int = 1
,@delaytype nvarchar ( 10 )="Minuten"
WIE
- T. Davidson
-- Diese gespeicherte Prozedur wird =WIE BESEHEN= ohne Gewährleistung bereitgestellt,
-- und Konferenzen keine Rechte.
-- Die Nutzung der enthaltenen Skriptbeispiele unterliegt den Bedingungen
-- angegeben unter http://www.microsoft.com/info/cpyright.htm
-- @num_samples ist die Häufigkeit, mit der Waitstats erfasst werden,
- Standard ist 10 Mal. Das standardmäßige Verzögerungsintervall beträgt 1 Minute
-- delaynum ist das Verzögerungsintervall. Verzögerungstyp gibt an, ob
-- das Verzögerungsintervall beträgt Minuten oder Sekunden
-- Waitstats-Tabelle erstellen, wenn sie nicht existiert, andernfalls abschneiden

keine Zählung setzen
falls nicht vorhanden (wählen Sie 1 aus sysobjects wobei name = "waitstats" )
Tabelle Waitstats erstellen (varchar( 80 ),
Anfragen numerisch ( 20 ,1 ),
numerisch ( 20 ,1 ),
numerisch ( 20 ,1 ),
jetzt datetime default getdate())
Andernfalls werden die Waitstats der Tabelle abgeschnitten

dbcc sqlperf (waitstats,clear) – Waitstats löschen

deklariere @i int
,@delay varchar ( 8 )
,@dt varchar ( 3 )
,@jetzt datetime
,@totalwait numerisch ( 20 ,1 )
,@Endzeit DatumZeit
,@begintime datetime
,@hr Int
,@min int
,@sec int

Wählen Sie @i = 1
select @dt = Kleinschreibung (@delaytype)
wenn "Minuten" dann "m"
wenn "minute", dann "m"
wenn "min" dann "m"
wenn "mm", dann "m"
wenn "mi" dann "m"
wenn "m" dann "m"
wenn "Sekunden" dann "s"
wenn "zweiter" dann "s"
wenn "sek" dann "s"
wenn "ss" dann "s"
wenn "s" dann "s"
sonst @delaytype
Ende

if @dt not in ("s" ,"m" )
Start
drucken "Bitte geben Sie den Verzögerungstyp an, z. B. Sekunden oder Minuten."
Rückkehr
Ende

if @dt = "s"
Start
select @sec = @delaynum % 60
select @min = cast((@delaynum / 60 ) als int)
select @hr = cast((@min / 60 ) als int)
wähle @min = @min % 60
Ende

if @dt = "m"
Start
@sec= auswählen 0
select @min = @delaynum % 60
select @hr = cast((@delaynum / 60 ) als int)
Ende

select @delay = right("0" + convert(varchar( 2 ),@hr), 2 ) + ":" +
2 ),@Mindest), 2 ) + ":" +
+ right("0" +convert(varchar( 2 ),@sec), 2 )

wenn @hr > 23 oder @min > 59 oder @sec > 59
Start
auswählen "hh:mm:ss Verzögerungszeit kann nicht > 23:59:59 sein"
wählen Sie "Verzögerungsintervall und geben Sie Folgendes ein: " + convert (varchar ( 10 )
,@delaynum) + "," + @delaytype + " konvertiert in "
+ @Verzögerung
Rückkehr
Ende

während ich<= @num_samples)
Start
einfügen in waitstats(, Anfragen,
,)
exec("dbcc sqlperf(waitstats)" )
Wählen Sie @i = @i + 1
warte auf Verzögerung @Verzögerung
Ende

Waitstat-Bericht erstellen
Führen Sie get_waitstats aus

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

CREATE proc get_waitstats
WIE
-- Diese gespeicherte Prozedur wird =WIE BESEHEN= ohne Gewährleistung bereitgestellt, und
-- Konferenzen keine Rechte.
-- Die Nutzung der enthaltenen Skriptbeispiele unterliegt den angegebenen Bedingungen
-- unter http://www.microsoft.com/info/cpyright.htm
--
-- Dieser Prozess erstellt einen Waitstats-Bericht, der Wartetypen auflistet nach
- Prozent
-- kann ausgeführt werden, wenn track_waitstats ausgeführt wird

keine Zählung setzen

Deklarieren Sie @now datetime
,@totalwait numerisch ( 20 ,1 )
,@Endzeit DatumZeit
,@begintime datetime
,@hr Int
,@min int
,@sec int

wähle @now=max (jetzt),@begintime=min (jetzt),@endtime=max (jetzt)
from waitstats where = "Gesamt"

Subtrahieren Sie waitfor, sleep und resource_queue von Total

select @totalwait = sum() + 1 von Waitstats
wo nicht in ("WAITFOR" ,"SLEEP" ,"RESOURCE_QUEUE"
, "Gesamt" , "***Gesamt***" ) und jetzt = @jetzt

Angepasste Gesamtsummen einfügen, nach Prozentsatz absteigend ordnen

Waitstats löschen, wobei = "***total***" und jetzt = @now

in Waitstats einfügen "***Gesamt***" auswählen
,0
,@totalwait
,@totalwait
,@jetzt

auswählen
,
,Prozent = Besetzung ( 100 */@totalwait als Zahl ( 20 ,1 ))
von Waitstats
wo nicht drin ("WAITFOR" ,"SLEEP" ,"RESOURCE_QUEUE" ,"Total" )
und jetzt = @jetzt
Sortieren nach Prozent absteigend

In dieser kurzen Anmerkung möchte ich ein wenig über die Feinheiten der Parallelitätseinstellungen in Microsoft SQL Server sprechen. Viele von Ihnen kennen seit langem die Option Max Degree od Parallelism, die seit sehr langer Zeit in SQL Server vorhanden ist. Standardmäßig ist es auf 0 gesetzt, was bedeutet, dass SQL Server den optimalen Parallelitätsgrad selbst wählt, dh die Anzahl der Prozessoren / Threads, die an der Ausführung einer Anweisung beteiligt sind. Ich werde jetzt nicht aufhören und diskutieren, auf welchen Wert es besser ist, diese Option einzustellen - dies ist ein Thema für eine separate Notiz. Ich werde nur betrachten, wie sich der Wert dieser Option auf die Ausführung von Abfragen auswirkt. In der Abbildung unten ist diese Option beispielsweise auf 1 gesetzt, was bedeutet, dass parallele Pläne für alle Abfragen standardmäßig deaktiviert sind.

Diese Option kann auch mit dem folgenden T-SQL-Befehl angezeigt werden:

Tatsächlich ist jeder standardmäßige Abfrageplan sequentiell. Zum Beispiel:

Der Entwickler und jeder Benutzer hat jedoch immer noch die Möglichkeit, dies durch die Verwendung von Hinweisen zu beeinflussen. Dazu muss lediglich der gewünschte Parallelitätsgrad angegeben werden und schon wird der gewünschte Abfrageplan generiert, z. B.:

Und wenn wir diese Abfrage über die Ansicht sys.dm_exec_query_profiles beobachten, sehen wir, dass sie tatsächlich in 10 Threads ausgeführt wird.

Somit verbleibt eine geheime Lücke im System, die Entwickler und Benutzer nutzen können, um ihre Abfragen zu „beschleunigen“ (hier habe ich es ausdrücklich in Anführungszeichen gesetzt, da ein hohes Maß an Parallelität nicht immer zu einer Verringerung der Abfrageausführungszeit führt). Erhöhung des Parallelitätsgrades . Aber auf diese Weise können sie den Server einfach "killen", indem sie viele unkontrollierte parallele Anfragen gleichzeitig starten. Was können wir dagegen tun? Abhilfe schafft hier der Resource Governor, ein sehr mächtiges und völlig unterschätztes System, mit dem Sie Ressourcen sehr flexibel auf verschiedene Benutzergruppen verteilen können. Auch hier werde ich nicht darauf eingehen, wie es funktioniert und welche Fähigkeiten es hat. Ich werde nur erläutern, wie sich die Einstellungen für die Gleichzeitigkeitsgrenze darauf auswirken. Werfen wir zunächst einen Blick auf die Standardeinstellungen:

Auch hier sehen wir, dass die Option standardmäßig auf 0 gesetzt ist und die Entscheidung, den maximalen Grad zu wählen, dem SQL Server überlassen bleibt. Mal sehen, was passiert, wenn ich diesen Wert auf 5 ändere. Ich habe nicht einmal eine Klassifizierungsfunktion für Resource Governor definiert und ändere die Standardgruppe. Aber für einen Test und um zu verstehen, wie alles in meinem Beispiel gerade funktioniert, reicht das. Daher beschränke ich den maximalen Parallelitätsgrad für alle auf 5 Threads. Daran erinnern, dass die Option Maximaler Parallelitätsgrad, die wir uns zuvor angesehen haben, ist immer noch auf 1 gesetzt. Wenn wir uns jetzt den Ausführungsplan unserer ursprünglichen Abfrage ansehen, dann ist er standardmäßig seriell und mit der Option maxdop 10 parallel. Aber wenn wir einen parallelen Plan durchführen, werden wir etwas Interessantes sehen.

Jetzt wird unsere Anfrage nur in 5 Threads ausgeführt, obwohl die Option maxdop sie hat einen Wert von 10. Und wenn Sie die maxdop-Option 4 für die Abfrage angeben, wird sie in 4 Threads ausgeführt (die Option in Resource Governor ist auf 5 gesetzt). In diesem Fall der Hinweis maxdop kleiner als die Einstellung der Ressourcenkontrolle, sodass keine zusätzliche Beschränkung auferlegt wird. Ich gebe dafür kein Beispiel mehr.

Somit ist Resource Governor ein leistungsfähigeres Werkzeug, das den maximalen Grad an Parallelität für Abfragen bereits stark einschränkt, und dieser Grad kann für verschiedene Benutzergruppen unterschiedlich eingestellt werden. Gleichzeitig die Option Maximaler Parallelitätsgrad funktioniert immer noch und leistet seinen Beitrag (oder verwirrt Administratoren, Entwickler und Benutzer leicht, wenn es mit Resource Governor gepaart wird). Darüber hinaus sind die Optionen zum Einstellen der Werte dieser beiden Parameter nur durch Ihre Vorstellungskraft begrenzt, aber es ist wichtig, sich nur an zwei Dinge zu erinnern: Maximaler Parallelitätsgrad und Hinweis maxdop für eine Anfrage beeinflusst, welcher Plan generiert wird, wie viele Threads maximal für diese Anfrage möglich sind, und Resource Governor schränkt die Anfrage von oben bereits zur Laufzeit weiter ein.

Ziel: Untersuchen Sie die Auswirkungen der SQL-Parallelität auf die Arbeit mit 1C-Abfragen

Literatur:

Test Umgebung:

Windows Server 2008 R2 Enterprise

MS SQL-Server 2008 R2

1C Enterprise 8.2.19.90

Abbildung 1. SQL-Eigenschaften „Allgemein“

Abbildung 2. SQL-Eigenschaften „Erweitert“

Werkzeug:

SQL-Server-Profiler

Abfragekonsole 1C

Testanfrage:

WÄHLEN

AK.Name AS-Name

AUS

Informationsregister Adressklassifikator AS AK

INNERE VERBINDUNG Informationsregister Adressklassifikator AS AK1

SW AK.Code = AK1.Code

Ausbildung:

Wir starten den SQL Server Profiler, stellen eine Verbindung her, markieren Ereignisse und Spalten wie in Abbildung 3 gezeigt.

Abbildung 3. Trace-Eigenschaften

Auswahl für unsere Basis einrichten

Abbildung 4. Filtern nach Datenbank

Abkürzungen:

Max. Parallelitätsgrad - MDOP

Kostenschwelle für Parallelität - Kosten

Testen eines sequentiellen Abfrageplans (MDOP = 1)

Abbildung 5. Abfragekonsole – 20 Sekunden Ausführungszeit

Der SQL-Server-Parameter „Max Degree of Parallelism“ ist auf 1 gesetzt (keine Parallelität). Das Ergebnis sehen wir uns im Profiler an (Abb. 6)

Abbildung 6. Sequenzieller Abfrageplan

SQL Server generierte einen sequentiellen Abfrageplan, während: Gesamt-CPU-Last = 6,750 (Sek.) und Abfrageausführungszeit = 7,097 (Sek.)

Paralleler Abfrageplantest (MDOP = 0, Kosten = 5)

Wir versetzen den SQL-Server in den Parallelitätsmodus (in SQL Query):

USE-Master ;

EXEC sp_configure "Erweiterte Option anzeigen" , 1;

NEUKONFIGURIEREN MIT ÜBERSCHREIBEN

USE-Master ;

exec sp_configure "maximaler Parallelitätsgrad" , 0;

NEUKONFIGURIEREN MIT ÜBERSCHREIBEN

Ausführen derselben Abfrage (Abbildung 7)

Abbildung 7. Abfragekonsole – 16 Sekunden Ausführungszeit

Überprüfung des Ergebnisses im Profiler (Abbildung 8)

Abbildung 8. Plan für parallele Abfragen

Der SQL-Server hat dieses Mal einen Plan für parallele Abfragen gebildet, mit der Gesamt-CPU-Last = 7,905 Sekunden und der Dauer der Abfrage = 3,458 Sekunden

Testen eines sequentiellen Abfrageplans (MDOP = 0, Kosten = 150)

Versuchen wir, den Parallelplan mit dem Parameter "Kostenschwelle für Parallelität" loszuwerden. Standardmäßig ist der Parameter auf 5 gesetzt. In unserem Fall ist es uns gelungen, die Bildung eines parallelen Plans mit einem Wert von 150 (in SQL Query) zu beseitigen:

USE-Master ;

exec sp_configure "Kostenschwelle für Parallelität", 150 ;

Wir prüfen die Ausführung der Anfrage unter diesen Bedingungen (Abb. 9)

Abbildung 9. Abfragekonsole – 20 Sekunden Ausführungszeit

Wir überprüfen das Ergebnis im Profiler (Abb. 10)

Abbildung 10. Sequenzieller Abfrageplan.

SQL Server hat einen sequenziellen Abfrageplan generiert. CPU-Auslastung insgesamt = 7,171 Sek., Ausführungszeit der Abfrage = 7,864 Sek.

Schlussfolgerungen:

Die Ausführung einer Testabfrage in der 1C-Enterprise-Umgebung mit einem parallelen SQL-Server-Abfrageplan ergibt einen erheblichen Leistungsschub im Vergleich zu einem sequentiellen Plan (16 Sek. vs. 20 Sek. - Gewinn von 4 Sek.)

Die Testabfrageausführung durch SQL Server selbst bei Verwendung eines parallelen Abfrageplans ist doppelt so schnell wie bei Verwendung eines seriellen Abfrageplans (3,5 Sekunden gegenüber 7,1 Sekunden).

Die Parallelität des SQL-Servers kann nicht nur über den Parameter MDOP, sondern auch über den Parameter „Сost threshold for parallelism“ angepasst werden

• Lernprogramm

Dieses Handbuch richtet sich an Anfänger, die nach einer einfachen Anleitung in russischer Sprache suchen, um die englische Version von SQL Server 2012 zu installieren, die für SharePoint 2013 verwendet wird.
Dieser Artikel ist nichts für Profis.

Alle Arbeiten sind in 3 Phasen unterteilt:

• Installieren von SQL Server 2012
• Festlegen der Serverkonfigurationsoption Max. Grad an Parallelität
• Konfigurieren der Rechte des Kontos, das SharePoint 2013 installieren soll

Der Artikel beschreibt auch den Prozess der Installation von Microsoft .NET Framework 3.5 auf MS Windows Server 2012 R2 Standard.

Achtung: Es gibt viele Bilder unter dem Schnitt!

Installieren von SQL Server 2012

1. Vor der Installation sollten Sie sicherstellen, dass genügend freier Speicherplatz auf Ihrer Festplatte vorhanden ist (in meinem Fall waren es 2,7 GB).
Wählen Sie nach dem Start des Distributionskits den Punkt " Installation" im linken Menü, dann "klicken" Sie auf das Element " Neuer eigenständiger SQL Server oder Hinzufügen von Funktionen zu einer vorhandenen Installation":

2. Der Installationsassistent wird gestartet. Er wird es überprüfen. Sie können auf die Schaltfläche "Details anzeigen" klicken und einen detaillierten Bericht anzeigen:

3. Ausführlicher Bericht. Drücken Sie die „OK“-Taste:

4. Geben Sie den Produktschlüssel ein und klicken Sie auf die Schaltfläche „Weiter“:

5. Wir stimmen den Bedingungen der Lizenzvereinbarung zu.
Aktivieren Sie dazu das Kontrollkästchen ich akzeptiere die Lizenzbedingungen

6. Wählen Sie im Schritt „Rolle einrichten“ den ersten Punkt „ SQL Server-Funktionsinstallation". Drücken Sie die Schaltfläche "Weiter":

7. Aktivieren Sie im Schritt "Funktionsauswahl" " Datenbank-Engine-Dienste", "Verwaltungstools-Basic" und " Verwaltungstools - Vollständig". Klicken Sie dann auf die Schaltfläche "Weiter":

8. Das Installationsprogramm führt dann eine weitere Überprüfung durch. Sie können auf die Schaltfläche "Details anzeigen" klicken und einen detaillierten Bericht anzeigen:

9. Ausführlicher Bericht. (Zu diesem Zeitpunkt habe ich einen Fehler in der Regel "Microsoft .NET Framework 3.5 ist installiert ..." erhalten. Mehr dazu weiter unten). Drücken Sie die Schaltfläche „Weiter“:

10. Im Schritt „Instance Configuration“ müssen Sie die Instanz des SQL Server-Dienstes konfigurieren.
Auch dieser Artikel ist für Anfänger. Daher gehen wir davon aus, dass SQL Server zuvor noch nicht auf Ihrem Server installiert wurde, was bedeutet, dass wir alle Standardeinstellungen belassen. Drücken Sie die Schaltfläche „Weiter“:

11. In diesem Schritt zeigt der Installationsassistent die Speicherplatzanforderungen an. Drücken Sie die Schaltfläche „Weiter“:

12. Beim Schritt „Serverkonfiguration“ müssen Sie ein Domänenkonto für den Dienst „ SQL Server-Datenbankmodul". Nachdem Sie die Felder "Kontoname" und "Passwort" ausgefüllt haben, klicken Sie auf die Schaltfläche "Weiter":

13. Beim Schritt „Datenbank-Engine-Konfiguration“ reicht es aus, den aktuellen Benutzer zu den SQL-Server-Administratoren hinzuzufügen. Klicken Sie dazu auf die Schaltfläche "Aktuellen Benutzer hinzufügen" und dann auf die Schaltfläche "Weiter":

14. Klicken Sie im nächsten Schritt auf die Schaltfläche „Weiter“:

15. Als nächstes führt der Installationsassistent den Test erneut durch und zeigt seine Ergebnisse an. Drücken Sie die Schaltfläche „Weiter“:

16. Beim Schritt „Bereit zur Installation“ zeigt der Assistent zusammenfassende Informationen an. Hier müssen Sie auf die Schaltfläche "Installieren" klicken:

17. Nach Abschluss der Installation werden Informationen zu den durchgeführten Vorgängen angezeigt:

18. Ich empfehle dringend, dass Sie Ihren Computer zu diesem Zeitpunkt neu starten. In einigen Fällen (z. B. bei der Installation von Microsoft .NET Framework 3.5) zeigt der Installationsassistent selbst ein Fenster an, in dem Sie aufgefordert werden, den Computer neu zu starten. Gib nicht auf.

Festlegen der Serverkonfigurationsoption Max. Grad an Parallelität

Der Standardwert für den Parameter "Max. Parallelitätsgrad" ist 0.
SharePoint 2013 erfordert, dass diese Einstellung 1 ist.
Es ist einfach zu beheben!

1. Laufen Microsoft SQL Server Management Studio(Start – Alle Programme – Microsoft SQL Server 2012 – SQL Server Management Studio).

2. Klicken Sie auf dem Bildschirm für die Serververbindung auf die Schaltfläche Verbinden.

3. Klicken Sie mit der rechten Maustaste auf Ihren Server im " Objekt-Explorer" und wählen Sie " Eigenschaften":

4. Wählen Sie im sich öffnenden Servereigenschaften-Fenster im linken Menü die Seite " Fortschrittlich" und scrollen Sie die Liste der Eigenschaften ganz nach unten auf dem Bildschirm. Stellen Sie den Wert des Parameters ein " Maximaler Parallelitätsgrad" in 1 und klicken Sie auf die Schaltfläche "OK":

5. Schließen Sie SQL Server Management Studio nicht, wir werden es noch brauchen.

Konfigurieren der Rechte des Kontos, das SharePoint 2013 installieren soll

Das Konto, unter dem SharePoint 2013 installiert wird, muss in SQL Server erhöht werden.
Es wird empfohlen, diesem Konto die folgenden Rollen zuzuweisen:

• dbcreator
• Sicherheitsadmin
• Öffentlichkeit

1. Im SQL Server Management Studio im Ordner „ Objekt-Explorer"Element erweitern" Sicherheit". Klicken Sie dann mit der rechten Maustaste auf das " Anmeldungen" und wählen Sie " Neues Login":

2. Geben Sie im Feld "Anmeldename" den Domänennamen des Kontos ein, unter dem Sie SharePoint 2013 installieren und konfigurieren möchten.

3. Wählen Sie im linken Menü die Seite " Serverrollen" und überprüfen Sie die Rollen "dbcreator" und "securityadmin" und stellen Sie sicher, dass die Rolle "public" bereits aktiviert ist. Klicken Sie dann auf die Schaltfläche "OK":

SQL Server ist jetzt bereit, SharePoint 2013 zu installieren.

Installation von Microsoft .NET Framework 3.5 auf MS Windows Server 2012 R2 Standard

In Schritt Nummer 9 des Absatzes " Installieren von SQL Server 2012" Ich habe eine Fehlermeldung erhalten: .NET Framework 3.5 wurde nicht installiert.
Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

1. Sie müssen die Konsole öffnen " Server Administrator".

2. Wählen Sie im linken Menü den Punkt „Dashboard“ aus.

3. Klicken Sie in der Mitte des Fensters auf den Punkt „Rollen und Features hinzufügen“.

4. Überspringen Sie im sich öffnenden Assistenten den Schritt „Bevor Sie beginnen“.

5. Wählen Sie im Schritt „Installationstyp“ „ Rollenbasierte oder funktionsbasierte Installation". Drücken Sie die Schaltfläche "Weiter".

6. Belassen Sie im nächsten Schritt alles auf den Standardwerten und klicken Sie auf die Schaltfläche „Weiter“.

7. Überspringen Sie den Schritt „Serverrollen“, indem Sie auf die Schaltfläche „Weiter“ klicken.

8. Aktivieren Sie im Schritt „Features“ das Kontrollkästchen „.NET Framework 3.5 Features“. Wir drücken die Schaltfläche "Weiter".

9. Nachdem der Installationsvorgang abgeschlossen ist, können Sie den Assistenten zum Hinzufügen von Rollen und Features schließen.

10. Fertig!

Alles Gute und friedlicher Himmel über deinem Kopf!

P.S. Alles Gute zum Tag der Kosmonauten!

Dieser Beitrag konzentriert sich nur auf MS SQL Server. Wenn Sie "Ihr Glück versuchen" und 1C mit Oracle, DB2, Postrgre verwenden, werden diese Informationen für Sie nutzlos sein. Aber Sie müssen verstehen, dass es in 1C vor allem Spezialisten für MS SQL Server gibt. Durch die Bemühungen von IBM gibt es auch DB2-Spezialisten. Man kann lange darüber streiten, ob das ein DBMS gut oder schlecht ist, eines ist wichtig, am „flüssigsten“ arbeitet 1C mit MS SQL Server. Nach den neuesten Meldungen von der "Front" zu urteilen, ist die Arbeit mit DB2 mehr oder weniger anständig geworden. Obwohl ich persönlich die Erfahrung gemacht habe, 1C für die Arbeit mit DB2 in Version 8.1 einzurichten, war dort irgendwie nicht alles sehr gut. In jedem Fall sollte die Wahl eines anderen DBMS klar begründet werden – entweder durch die Möglichkeiten, die MS SQL nicht bietet (ein Cluster mit Loadbalancing, Grid etc.), oder durch die Finanzen (Oracle wurde bereits gekauft), oder durch die Plattform (alles ist auf Linux).

Also, in der Reihenfolge, was mit MS SQL Server getan werden muss:

1) Stellen Sie den minimalen und maximalen Speicher ein. Das Minimum ist die Hälfte des Systemspeichers. Maximum - Systemspeicher ohne 2 GB. Dies erfolgt über Management Studio - in den Servereigenschaften:

2) Wenn die Priorität nicht auf der Registerkarte "Prozessoren" eingestellt ist, müssen Sie sie einstellen

3) Setzen Sie den maximalen Parallelitätsgrad auf 1.

4) Aktivieren Sie den SQL Server Agent, richten Sie Database Mail ein - dort gibt es nichts Schwieriges, ich werde es nicht im Detail beschreiben.

5) Richten Sie Servicepläne ein:
Allgemein:
a) Statistikaktualisierung - alle 2 Stunden
b) DBCC FREEPROCCACHE - alle 2 Stunden
Für jede Basis:
a) Vollständige Sicherung
b) Differentielles Backup
c) Index-Defragmentierung - jeden Tag
d) Index-Wiederaufbau – Wochenendnächte
e) Überprüfung der Integrität der Datenbank - einmal im Monat nachts am Wochenende

6) Ich empfehle, das Wiederherstellungsmodell für jede Datenbank (in den Eigenschaften) als Einfach festzulegen. Wenn Sie kein 24/7-System und weniger als 1000 Benutzer pro Datenbank haben, gibt es kein Failover-Cluster und Sie haben kein SLA unterzeichnet, in dem Sie sich verpflichten, Daten im Falle eines Ausfalls von Geräten sekundengenau wiederherzustellen (und nicht ab dem Zeitpunkt der letzten Sicherung) wäre diese Empfehlung sinnvoll. Sonst werden Sie sehr bald lange und hektisch überlegen, wo Sie das überwucherte Tranzaction-Log hinstellen sollen

7) Entfernen Sie die tempdb-Datenbank von den regulären Datenbanken auf eine andere Festplatte – selbst wenn dies bedeutet, dass das RAID-Array neu konfiguriert und seine Leistung beeinträchtigt wird. Andernfalls kann 1 Benutzer die Arbeit aller anderen lahmlegen. Wenn Sie anstelle einer Festplatte einen Hardwarebeschleuniger haben, können Sie ihn natürlich nicht trennen und tempdb darauf legen, aber dies geht nur, wenn einer vorhanden ist

8) Installieren Sie ein Überwachungstool - ich mag zum Beispiel Spotlight http://www.quest.com/spotlight-on-sql-server-enterprise/

9) Testen Sie sich selbst mit Microsofts Best Practice Analizer - http://www.microsoft.com/download/en/details.aspx?id=15289 - ein tolles Tool, das nicht nur bei Einstellungen hilft, sondern auch bei der Lösung vieler Probleme.

Nun, kurz gesagt, wofür wir das alles getan haben:

1) Erinnerung. Der Mindestwert wird Sie einfach vor "Störungen" bewahren, wenn der SQL-Server aus irgendeinem Grund, der nur ihm bekannt ist, nicht den gesamten ihm zur Verfügung stehenden Speicher verwendet. Muss alles essen! Der Maximalwert erspart Ihnen das Austauschen, falls derselbe SQL Server-Speichernutzungsoptimierer entscheidet, dass es nicht schaden würde ....

3) Ein sehr wichtiger Punkt - IHMO muss in allen Transaktionssystemen auf 1 gesetzt werden. Erstens verhindert es einige der Sperren zwischen verschiedenen Prozessen, die versuchen, eine Anfrage auszuführen, und bewahrt uns dementsprechend vor einigen "seltsamen" Fehlern. Zweitens... 1 "tötende" Anfrage wird in der Lage sein, alle Ressourcen des Servers zu übernehmen, was im Verhältnis zu anderen Benutzern des Systems etwas unfair ist.Der Parameter selbst bestimmt, wie viele Prozessorkerne 1 Anfrage verarbeiten können.

5) Über Statistiken und das Löschen des prozeduralen Caches - das ist "nach Gehör", aber wir vergessen oft die Neuindizierung. Inzwischen ist dieses Verfahren ziemlich wichtig, insbesondere mit dem Wachstum des Volumens der Datenbank nimmt seine Bedeutung zu. Manchmal gehen bis zu 60 % der Leistung bei der Indexfragmentierung verloren.

7) Wenn Sie einen Hardwarebeschleuniger oder nur 2 Platten mit unterschiedlichen Zugriffsgeschwindigkeiten haben, würde ich auch empfehlen, über die Zuweisung von Dateigruppen in den Datenbanken nachzudenken und einzelne Tabellen in verschiedene Plattenarrays mit unterschiedlichen Zugriffszeiten aufzuteilen. Immerhin müssen Sie zugeben, dass das PH „Lagerware“ und das Nachschlagewerk „Aufbewahrung von Zusatzinformationen“ 2 Objekte sind, deren Anforderungen an die Aufbewahrung grundlegend unterschiedlich sind. Es ist nicht notwendig, alle Dateien und Bilder in der Datenbank in einem schnellen Array zu speichern - Sie können es in ein separates Array aufteilen, nicht so schnell, aber dort, wo viel Platz vorhanden ist (und keine Angst haben, einen Haufen hochzuladen Dateien übrigens später in die Datenbank).