SQL 2016 alle DBs in eine Instanz oder mehrere Instanzen

[meinerjunge 10]

Hallo,

 

ich möchte einen neuen SQL 2016 (virtuell) in Betrieb nehmen und unsere alten SQL Server (teils blech und virtuell) auf diesen Umziehen.

 

Nun stellt sich für mich die Frage, ob ich alle DBs in eine Instanz aufnehme oder diese auf mehrere verteile.

 

Den Vorteil von mehreren Instanzen sehe ich in den, ja :-) , mehreren getrennten Insatnzen welche ich unabhängig warten, runterfahren und konfigurieren kann.

Nachteil ist sicherlich der erhöhte Ressourcenverbrauch.

 

Gibt es weitere Aspekte welche für oder gegen mehrere Instanzen sprechen?

Wie ist eure Meinung dazu?

 

 

MfG Meiner

[NilsK 2.934]

Moin,

 

die Nachteile mehrerer Instanzen werden durch die Vorteile praktisch nie aufgewogen. Solange es also keine zwingenden Gründe für mehrere Instanzen gibt, gehören alle Datenbanken in dieselbe Instanz.

 

Gruß, Nils

[Sunny61 806]

Wenn die Datenbank auch von externen Dienstleistern immer wieder gewartet oder per TV supported werden, sollte man über eine eigene Instanz nachdenken.

[Dukel 454]

Wozu? Man kann dem Dienstleister immer noch nur die Rechte geben, die er benötigt und z.B. keine Sysadmin Rechte.

[meinerjunge 10]

Wenn die Datenbank auch von externen Dienstleistern immer wieder gewartet oder per TV supported werden, sollte man über eine eigene Instanz nachdenken.

 

Wozu? Man kann dem Dienstleister immer noch nur die Rechte geben, die er benötigt und z.B. keine Sysadmin Rechte.

 

 

Manche DL verlangen sogar ausdrücklich von uns SYSADMIN Rechte für die Instanz in der deren DB läuft.

Daher geht meine Überlegung in die Aufspaltung mehrerer Instanzen. Bin mir nur nicht im klaren ob es daher ratsam ist, vll. 20 SQL Instanzen auf einem Server zu betreiben und dies zu komischen Effekten führt, oder die Server gleich komplett zu trennen, was natürlich bzgl. der Lizenzkosten "uncool" ist.

[NilsK 2.934]

Moin,

 

also, 20 Instanzen sind garantiert ein Problem. Das Speichermanagement des SQL Servers greift instanzweit. Sobald du mehr als eine Instanz hast, musst du selbst für die RAM-Aufteilung sorgen. Das willst du aber nicht. "Komisch" würde ich die Effekte dann nicht nennen, aber du wirst erheblichen Aufwand damit haben und die Effizienz deines Datenbankservers opfern.

 

Kläre mit den Dienstleistern, was sie wirklich benötigen. Wenn sie für eine Datenbank zuständig sind (oder für die Applikation, die darauf zugreift), brauchen sie ganz sicher keine sysadmin-Rechte. Oft ist es so, dass solche Dienstleister die Interna des SQL Servers gar nicht kennen und z.B. von Oracle abstrahieren, das aber an der Stelle eine ganz andere Architektur hat. Mehrere Instanzen sind eine Notlösung, kein vorgesehenes Design.

 

Gruß, Nils

[wiri 10]

Hi

wir standen vor dem selben Problem! Viele Systeme mit je einem Hersteller und der entsprechenden Software.

Haben versucht möglichst wenig Instanzen zu bauen und verschiedene DBs zusammen zu betreiben.

Sind davon abgewichen, da viele Hersteller beim Betrieb die Server-Collation mit ihrer Db vergleichen und die ist nicht immer gleich. Dann brechen die den Update oder den Betrieb ab. Anderer Fall war, das eine Software immer nur eine leere Instanz vorfinden wollte. Ne andere hat einfach namensgleiche DB gelöscht oder gleich mitbenutzt, somit DatenKuddelmuddel. Somit fahren wir pro Fremdhersteller in einer Instanz, dann mehrere auf einer VM.

[zahni 554]

@Win,

 

manchmal sollte  man Lösungen vor  dem Einsatz vailidieren und wenn sie nicht in die Systemumgebung passen...

[Doso 77]

Wie immer: Kommt drauf an.

 

Ich würde z.B. Sharepoint seine eigene Instanz spendieren, aber der Rest sollte wenn möglich in eine Instanz.

[Dukel 454]

Wenn es möglich ist sollte man eher einen eigenen Server verpassen statt einer Instanz.

[NilsK 2.934]

Moin,

 

Ich würde z.B. Sharepoint seine eigene Instanz spendieren

 

warum?

 

Gruß, Nils