Ich habe einen vernünftigen Server an ein SAN angeschlossen, auf dem SQL-Server für mehrere derselben Anwendung ausgeführt werden. Es gibt keine Sicherheitsprobleme, wenn eine Anwendung die Datenbank einer anderen lesen kann.
Wir verwenden leider auch 32-Bit-Windows.
Ich bin der Meinung, dass es besser wäre, eine Instanz auf dem Server zu verwenden, AWE zu aktivieren, sodass die Serverinstanz fast den gesamten verfügbaren RAM nutzen kann, und dann jede der Datenbanken in einer Instanz auszuführen.
Allerdings haben mich die Götter der IT-Abteilung in diesem Punkt überstimmt, daher bin ich wirklich neugierig, Ihre Meinung dazu zu hören. Liege ich aus Leistungssicht falsch, wenn ich sage, dass eine SQL-Instanz besser ist als zwei?
Ich weiß, dass wir einige Failover-Sachen machen könnten, aber das auf einem Blade zu machen, scheint mir übertrieben.
Antwort1
SQL Server 2000 und 2005 Workgroup und Standard (32 Bit, bei 64 Bit bin ich mir nicht sicher) verwenden maximal 2 GB Speicher. Wenn Sie also zwei Instanzen haben, können Sie die vollen 4 GB verwenden. Dies gilt sogar, wenn Sie 32-Bit-SQL-Standard unter x64 Windows ausführen, und zwar umso mehr, da Sie eine Instanz pro 2 GB Speicher benötigen.
Grundsätzlich ist die Verwendung einer einzelnen Instanz mit zwei Datenbanken schneller als die Verwendung von zwei Instanzen mit jeweils einer Datenbank, obwohl ich nicht überzeugt bin, dass der Unterschied so groß ist. Separate Instanzen können für die Verwaltung nützlich sein. Wenn Sie beispielsweise SQL-Anmeldungen verwenden und es unterschiedliche Anmeldesätze für unterschiedliche Datenbanken gibt, kann die Verwendung separater Instanzen die Nachverfolgung der Anmeldungen erleichtern.
Die Antwort auf Ihre Frage ist also: „Es kommt darauf an“ :-)
JR
Zu Spences Kommentar: SQL Server Standard unter 32-Bit-Windows kann maximal 2 GB Speicher verwenden. SQL Server Enterprise kann 3 GB verwenden, wenn Sie den Schalter /3GB verwenden. Unter Windows 2003 Enterprise mit AWE können bis zu mindestens 16 GB Speicher verwendet werden (möglicherweise mehr), sodass Sie Ihren Speicher besser nutzen können, indem Sie mehr als eine Instanz von SQL Server ausführen.
Ich fürchte, die Antwort lautet immer noch „es kommt darauf an“. Wenn Sie viel Speicher haben, z. B. 8 GB oder 16 GB, möchten Sie die größten Datenbanken in separaten Instanzen unterbringen, sodass jede 2 GB (oder 3 GB mit /3GB) hat. Wenn Sie nur 4 GB haben, würde ich wahrscheinlich eine einzelne Instanz und den /3GB-Schalter verwenden, da der geringe zusätzliche Speicherbedarf durch zwei Instanzen den Mehraufwand nicht wert wäre.
Wie andere unten kommentiert haben, können noch weitere Überlegungen angestellt werden. Wenn Sie gleichzeitig auf zwei Datenbanken verweisen, z. B. in einer Auswahlabfrage oder wenn Sie von einer Datenbank in eine andere einfügen, möchten Sie sie aus Geschwindigkeitsgründen in derselben Instanz haben.
Antwort2
32 Bit ist eine Sackgasse.
In SQL2K5 ist der Speicherverbrauch für Dinge wie die Plankompilierung, die Plangröße selbst und damit der Proc-Cache deutlich auf über 2 KB gestiegen. Auch andere Komponenten wie der Berechtigungstoken-Cache neigen dazu, zu wachsen, wenn Sie viele Benutzer haben (d. h. große Organisationen und Impersonates der mittleren Ebene). Da all diese nicht von AWE profitieren können, ist es schwierig, ein ausgelastetes System in einen 32-Bit-Speicherplatz zu packen. Wenn Sie komplexe Abfragen und Pläne haben, kann das Aggregieren der Instanzen dazu führen, dass ein sehr hoher Prozentsatz des Pufferpools gestohlen wird, sodass ein kleiner Pufferpool für Daten übrig bleibt, was zu einer ständigen Cache-Auslagerung kompilierter Pläne und einer geringen Seitenlebensdauer führt.
Andererseits neigen mehrere SQL-Instanzen auf derselben Maschine dazu, sich gegenseitig in die Quere zu kommen und so gegenseitigen Speicherdruck auszulösen. Da die Speichermanager der Instanzen nicht miteinander kommunizieren, ist es viel schwieriger, ein Gleichgewicht zu finden als bei einer einzelnen Instanz. Auch die Prozessorplanung mehrerer Instanzen kann unter ähnlichen Problemen leiden, da das Betriebssystem die SQL-Scheduler zwischen den Instanzen unterbricht, was zu einer Überlastung des CPU-Cache führt.
Antwort3
Meiner bescheidenen Meinung nach liegen Sie, die Götter der IT, in diesem Punkt falsch. Solange es keine Sicherheitsbedenken gibt, die durch das Ausführen mehrerer Datenbanken in derselben Instanz zu berücksichtigen sind, ist das der richtige Weg. Mehrere Instanzen verursachen immer einen gewissen Overhead, der effektiv zu einer suboptimalen Leistung Ihres Servers führt. Aus Administratorsicht ist es auch besser, bei einer Instanz zu bleiben.
Antwort4
Wie immer kommt es darauf an:Müssen die Datenbanken jemals miteinander „sprechen“?
Wenn es sich um dieselbe Anwendung handelt, werden Sie häufig Situationen erleben, in denen Sie möchten, dass eine Datenbank aus der anderen liest oder in sie schreibt. In diesem Fall sind zwei Datenbanken auf einer einzigen Instanz vorzuziehen. (Keine verknüpften Server, gemeinsame Anmeldungen, gemeinsame Tempdb sind hier alles Vorteile.)
Wenn die beiden Datenbanken jedoch vollständig isoliert sind und nie miteinander kommunizieren und tatsächlich nichts miteinander zu tun haben (z. B. SharePoint und SAP), sind zwei Instanzen möglicherweise vorzuziehen. (Die Möglichkeit, auf verschiedenen Service Pack-Ebenen ausgeführt zu werden oder den von einer Instanz verwendeten Speicher zu begrenzen, sind zwei Vorteile, die mir spontan einfallen.)