SQL 2022 Standard Installation so machen, das nicht beanstandbar

Moin,

Leg mal drei Partitionen an:
D:\ Hier landen die mdf-Files
E:\ für die LogFiles (ldf)
F:\ Pfad für Backups

I.d.R. Belässt man es bei der Standard-Instanz „MSSQL“
Und daraus ergibt sich dann auch dein Limit für den RAM: Default belassen. Der SQL nimmt/ reserviert das, was noch frei ist.


Ansonsten frag halt den ERP-Hersteller (wer ist das eigentlich?). Der sagt dir dann, was du alles machen sollst.

Moin.

Ich widerspreche @em-pie ja nur ungern - aber benannte Instanzen halte ich für extrem wichtig, ich würde z.B. niemals den Standard-Namen "MSSQL" verwenden. Aber das ist eher philosophisch, rein technisch isses wurscht.

Für den Betrieb der SQL-Sever-Dienste rate ich dringend zum Einsatz von gMSA, wie z.B. hier beschrieben:
https://www.mssqltips.com/sqlservertip/5340/using-group-managed-service- ...

Im AD gibt's immer eine (DL-)Gruppe "SQL-Admins", die bei der Installation direkt eingetragen wird. Ich belasse es meist bei Windows-Authentifizierung, gemischter Modus wird nur aktiviert, wenn die Anwendung es so haben muss (viele Applikationen verbinden sich per default von jedem Client als sa auf die SQL-Instanz, sehr oft steht dann das sa-Passwort im Klartext in einer .ini-Datei im Installatiospfad der Anwendung...).

Ein nachträglicher Wechsel von reiner Windows-Authentifizierung zu gemischter Authentifizierung und zurück ist problemlos möglich.

Fixe TCP-Ports für die Instanz, entsprechende Firewall-Regeln, deaktivierte Telemetrie-Dienste und Vorsicht beim Benutzen des SQL-Browsers gehören bei mir meist auch zum Standard-Setup, wenn ich MSSQL installieren.

Anzahl Cores und Temp-Files ist auch nicht ganz unwichtig (Lizenzierung beachten!), aber das wird ja i.d.R. durch die Applikation vorgegeben. Ob nun Datenbank-, Log- und Backup-Dateien zwingend auf unterschiedliche Partitionen verteilt werden müssen, ist auch eher eine philosophische Frage bzw. eine Frage der Anforderung der Software. Da ERP-Systeme meist "Schwergewichte" sind, wäre es da wohl ratsam, das so zu machen - Details dazu gibt dir der Hersteller. Auch hier ist ein nachträgliches Verschieben der Dateien, falls doch mal alles im Standardordner gelandet ist, möglich und machbar.

Essentials ist Wahl der korrekten "Database-Collation" während des Setups, die lässt sich nur mit viel Mühe ändern (falls überhaupt). Meist ist "General-Latin1-CI-AS" eine gute Wahl, aber auch hier kann bzw. muss dir der Software-Anbieter sagen, was er benötigt. Sollte der, was ich schon erlebt habe, keine Ahnung haben was du "Database-Collation" überhaupt meinst, ist "General-Latin1-CI-AS" die beste Wahl, denn das ist die Default-Einstellung.

Bestimmt habe ich noch ein paar Dinge vergessen, aber so im groben sollte das dir eine Richtung zeigen.

Cheers,
jsysde

Hallo,

ich würde mal folgendes in den Raum werfen. Ein SQL Server kann entweder vernünftig installiert werden oder so wie es der ERP Hersteller will.

Somit in dem Fall nix selbst machen dann kann der Hersteller im Zweifelsfall nicht abschieben.

Moin,

Sehe ich wie @wiesi200, lass den ERP Hersteller die Installation machen. Falls es später Probleme gibt, können die dann nicht sagen, es liegt an deiner SQL Installation.

Gruß,
Avoton

Moin

... genau. Den SQL-Server installierst Du so, wie es der Hersteller/Lieferant der Software gerne haben möchte. Hast Du da keine Infos drüber, lässt Du es bleiben.

Gruß

OS, SQL-Installation, Tempdb und eigentliche DB kann man alle auf unterschiedliche Partitionen legen. Wenn die aber am Ende alle auf dem selben Storage landen, ist das auch nicht das Wahre Die Installation habe ich auf C:, die wird nicht sonderlich wachsen. Alle Datenbanken habe ich auf einer eigenen Partition.

Ich hatte Probleme mit Eval als ich erst SQL aktiviert habe und dann das OS aktivieren wollte. Ich weiß nicht, warum, aber SQL wollte im Anschluss nicht aktiviert sein (obwohl es einmal durchgelaufen ist) und dann nicht neu aktivieren. War mir dann zu blöd, neues Setup...

der Punkt ist wenn was voll läuft dann meist LOGS
und wenn du die auf einer eigenen Parition hast zerlegts dir wenigstens nicht dein C: Betriebsystem und auch nicht deine Datenbankfiles....
Kann passieren wenn du mal eine grosse aktion im SQL fabrizierst und dann auf einmal tonnen Logs generiert werden mit dem du nicht gerechnet hast.
Daher Backuppartition kann man sich drüber streiten, aber auch hier wenn Datenbank anschwillt, und dein Backup damit auch, und die partition dicht läuft, betrifft es wenigstens nicht dein Produktives system. Wenn du aber nur 2 Partitionen
c: system
d: Datenbanken
hast, fliegt dir hier schon mal was um die ohren wenn du pech hast.

dem schliesse ich mich an. auch der mode kann jeh nach ERP system wichtig sein, also mixed mode oder nur mit dem sa user oder oder... wir hatten mal ein ERP system wo den zugriffs unterschied erkannt hat und sich dann unterschiedlich verhalten hat... ultra schräg... daher immer exakt mit ERP hersteller absprechen.
Am besten fragen was will er haben, CPU und RAM und Partitionen und Grössen.
Und dann genau so installieren und SQL mit ihm zusammen installieren lassen und das ERP dann auch.
Dann wird nix schief gehen. und ERP Hersteller kann sich niemals rauswinden, weil das machen sie auch gerne...
wenns später performance probleme gibt oder sonstige sachen die halt nicht gescheit laufen.

Ja vom Gedanken her richtig. Aus Erfahrung kann ich nur sagen gab es noch nicht bei mir. Muss jeder selbst abwägen, bei einem 10 User ERP halte ich die Risiken für überschaubar.

Was ich hingegen schon hatte war eine kaputte DB weil die Datenbankpartition bei einer Migration mit Konvertierung voll gelaufen ist. Das hatten weder ich noch der DL kommen sehen, die Platte war zuvor nur etwas mehr als 50% belegt. Ist auch immer blöd nur für eine Umstellung die Partition mit Platz zu versorgen, den man danach lange nicht mehr braucht aber nur schlecht wieder frei bekommt. Wenn ich, um sicher zu gehen, viele Partitionen anlege und alle mit ausreichend Platz bestücke dann wird mein Server schnell unangenehm groß. Grade schnelles Storage kostet bei uns schon was