Mehrere SQL Instanzen auf einem Server

[phatair 39]

Hallo zusammen,

 

wir haben einen SQL 2017 Standard Server der im Moment mit einer SQL Instanz läuft. 

In dieser ist eine DB vorhanden, die für eine Applikation genutzt wird. Die Instanz heißt auch wie die Applikation.

 

Nun benötigen wir eine weitere DB für eine andere Applikation. Kann ich dafür einfach eine weitere Instanz hinzufügen oder ist es besser eine Instanz zu besitzen in der alle DBs liegen?

Das würde dann natürlich dafür sprechen, die Instanzen nicht nach den Applikationen zu benennen.

 

Wenn ich unterschiedliche Funktionen benötige, muss ich ja eine weitere Instanz anlegen, oder?

 

Vielen Dank schon mal.

Gruß

[NilsK 2.940]

Moin,

 

mehrere Instanzen braucht man nur in Ausnahmefällen. Der Normalfall ist, dass dieselbe Instanz mehrere bzw. "alle" Datenbanken hält. Dann funktioniert auch das Memory Management am besten.

 

Gruß, Nils

 

[phatair 39]

Hi Nils,

Ok, dass heißt dann auch - habe ich ein Feature bisher noch nicht für die Instanz installiert. Füge ich es eben später der Instanz hinzu.

 

Dann wäre in unserem Fall wohl die beste Vorgehensweise - neue Instanz mit neutralen Namen erstellen, bestehende DB umziehen, alte Instanz löschen.

Oder übersehe ich hier etwas?

 

 

 

[NilsK 2.940]

Moin,

 

naja, was für ein Feature würdest du nicht installiert haben? Aber ja, im Prinzip hieße es das.

 

Du kannst die bestehende Instanz auch so lassen, ein Umzug ist technisch nicht nötig.

 

Gruß, Nils

 

[testperson 1.687]

Hi,

 

ggfs. solltest du das noch, sofern vorhanden, mit dem Hersteller der Applikation(en) klären, ob die das so unterstützen. Es gibt immer wieder Hersteller, die (mindestens) auf eine eigene Instanz pochen und ansonsten (angeblich) den Support verweigern.

 

Gruß

Jan

[phatair 39]

vor 21 Minuten schrieb NilsK:

naja, was für ein Feature würdest du nicht installiert haben? Aber ja, im Prinzip hieße es das.

 

Die neue Applikation benötigt z.B. das Feature "Integration Services". Das hatten wir bei der bestehenden Instanz nicht installiert, da die bestehende Applikation das nicht benötigt hat.

Bisher habe ich mich beim Anlegen der Instanz und deren Features immer daran orientiert, was die Applikation benötigt.

vor 21 Minuten schrieb NilsK:

Du kannst die bestehende Instanz auch so lassen, ein Umzug ist technisch nicht nötig.

 

Du meinst damit, auf dem SQL Server einfach 2 Instanzen weiterhin laufen lassen. Dann haben wir dort eben eine "named Instanz" und eine "neutrale Instanz" in der in Zukunft alle DBs laufen?

 

vor 13 Minuten schrieb testperson:

ggfs. solltest du das noch, sofern vorhanden, mit dem Hersteller der Applikation(en) klären, ob die das so unterstützen. Es gibt immer wieder Hersteller, die (mindestens) auf eine eigene Instanz pochen und ansonsten (angeblich) den Support verweigern.

Das war der Grund, warum ich das bisher (auf einem SQL Express) so gemacht hatte. Dort hatte ein Hersteller genau diese Anforderung.

Ich dachte nun, wenn es technisch keine Nachteile bietet, dass man das standardmäßig so macht. 

 

Aber das Thema shared Memory ist natürlich schon ein Grund, dass nicht einfach so zu machen.

 

EDIT: Gerde mit dem Hersteller der neuen Applikation gesprochen - die wollen natürlich eine dedizierte DB Instanz... Wahrscheinlich sagt das jetzt jeder, den wir fragen 

bearbeitet 15. März 2019 von phatair

[v-rtc 88]

vor 21 Minuten schrieb phatair:

EDIT: Gerde mit dem Hersteller der neuen Applikation gesprochen - die wollen natürlich eine dedizierte DB Instanz... Wahrscheinlich sagt das jetzt jeder, den wir fragen 

Gut möglich, hatte auch schon solche Applikationen. Bei MSSQL verstehe ich das jedoch nicht ganz und auch bei DB2 macht es nicht wirklich Sinn. 

*offTopic* Bei Postgress, laut einem Kollegen, können die immer nur die Instanz Restoren, also alles. Da macht es definitiv Sinn, sofern das wirklich so ist,

 

[zahni 554]

Bei MS-SQL wäre es nur interessant, wenn eine DB explizit andere Instanz-Parameter braucht. Davon gibt es aber nicht so viele.

Vielleicht "max degree of parallelism" oder filestream...

Ansonsten: Lieber Hersteller: Du muss damit zurechtkommen, was wir Dir anbieten.

Bei DB2 mache ich das auch nicht. Oracle will für jede DB einen eigenen Prozess haben (das nervt...)

[NilsK 2.940]

Moin,

vor 45 Minuten schrieb phatair:

Du meinst damit, auf dem SQL Server einfach 2 Instanzen weiterhin laufen lassen. Dann haben wir dort eben eine "named Instanz" und eine "neutrale Instanz" in der in Zukunft alle DBs laufen?

 

nein, ich meine eine einzige Instanz. So ist SQL Server entworfen und nur so läuft er optimal. Eine Aufteilung in mehrere Instanzen auf derselben Maschine ist immer eine Krücke mit teils erheblichen Nachteilen. Und wie andere schon richtig sagen - wenn Applikationshersteller auf sowas bestehen, liegt es meist daran, dass sie das System nicht verstehen.

 

Gruß, Nils

 

 

[phatair 39]

Das werde ich jetzt auch so machen - es sind 2 Anwendungen die auch relativ überschaubar sind und keine besonderen Ansprüche an den SQL haben.
Das ist wie mit den Festplatten - hier will jeder Hersteller immer gleich 100GB und am Ende werden nur 40GB genutzt.

@NilsK Ich müsste aber eine neue Instanz erstellen und dann die bestehende DB umziehen, da ich ungern die "named Instanz" für alle zukünftigen DBs verwenden möchte. Das verwirrt dann doch, wenn die Instanz suggeriert, dass sie für eine bestimmte Applikation ist.
Wenn ich dich richtig verstehe, meinst du, dass es technisch möglich ist die bestehende Instanz weiter zu verwenden und einfach alle DBs darin zu nutzen. Nur der Instanz Name bleibt halt "falsch".
Das umbenennen einer Instanz scheint ja nicht zu funktionieren.

[zahni 554]

Die meisten Lösungen verwenden so oder so nur einen SQL-Login via Port 1433. Da  ist  der Name der Instanz meistens egal.