Bessere Art der dynamischen Auswahl einer anderen Datenbank als sp_executesql

Question

Ich bin auf der Suche nach einer Hochverfügbarkeitsarchitektur, wobei zwei Spiegel-Datenbanken existieren (DB1 & DB2), die eine andere Datenbank mit Sichten (DBV) dienen. DB1 hat das Overnight-ETL, während DBV auf DB2 schaut, bis das ETL auf DB1 abgeschlossen ist, zu welchem ​​Zeitpunkt seine Ansichten zu den zugrundeliegenden Tabellen auf DB1 wechseln. Sobald der ETL auf DB1 abgeschlossen ist, wird DB2 mit DB1-Daten vor dem ETL des nächsten Tages wiederhergestellt. Am nächsten Tag wechseln DB1 und DB2 die Rollen.

Ich bin auf der Suche nach einer besseren/sichereren Möglichkeit, zwischen den beiden Ansichten zu wechseln, als sp_executesql auszuführen, um eine dynamisch erstellte Zeichenfolge auszuführen. Ich werde auch nach gespeicherten Prozeduren aus einer Staging-Datenbank suchen, bei denen die Skripts dynamisch geändert werden müssen, damit die richtige Datenbank für die Ausführung der ETL verwendet werden kann. Im Wesentlichen möchte ich die USE-Anweisung dynamisch übergeben und dann den Rest des Skripts außerhalb einer dynamischen Anweisung ausführen.

Ich möchte sp_executesql aus Support-Gründen für andere Entwickler vermeiden und auch um eine mögliche umfangreiche Verkettung von Strings umgehen, wenn die gespeicherte Prozedur/Ansicht besonders lang wird.

Irgendwelche Ideen/unterschiedliche Ansätze zur Hochverfügbarkeit in diesem Zusammenhang wären zu begrüßen.

Answer 1

Eine Option könnte eine Kopie jeder Ansicht in DBV für beiden Zieldatenbanken erstellen sein - das heißt

some_schema.DB1_myview 
some_schema.DB2_myview 

und dann ein synonym verwenden, um die Ansichten unter ihren endgültigen Namen zu belichten.

CREATE SYNONYM some_schema.myview ON some_schema.DB1_myview 

Ihr Switch-Prozess müsste dann nur die Synonyme und nicht die Views selbst löschen und neu erstellen. Dies müsste immer noch mit einer dynamischen SQL-Anweisung gemacht werden, aber die Komplexität wäre viel geringer.

Ein Nachteil wäre, dass das Risiko besteht, dass die Definitionen der zugrunde liegenden Ansichten nicht mehr synchron sind.

---

bearbeiten

Auf Kosten von mehr Risiko von out of sync bekommen, wäre es möglich, insgesamt dynamische SQL zu vermeiden, durch die Schaffung von (zum Beispiel) ein Paar von gespeicherten Prozeduren, von denen jeder erzeugt die Synonyme für die eine oder die andere Datenbank. Ihr Vermittlungscode müsste dann nur herausfinden, welcher Vorgang angerufen werden soll.

Answer 2

Haben Sie erwogen, die Datenbanken umzubenennen, während Sie die Dinge umschalten? I.e. die folgenden Drucke 1, gefolgt von 2, nichts in DBV hatten geändert werden:

create database DB1 
go 
use DB1 
go 
create table T (ID int not null); 
insert into T(ID) values (1); 
go 
create database DB2 
go 
use DB2 
go 
create table T (ID int not null); 
insert into T(ID) values (2); 
go 
create database DBV 
go 
use DBV 
go 
create view V 
as 
    select ID 
    from DB1..T 
go 
select * from V 
go 
alter database DB1 modify name = DBt 
go 
alter database DB2 modify name = DB1 
go 
alter database DBt modify name = DB2 
go 
select * from V 

Offensichtlich bessere Namen als 1 und 2 verwendet werden. Auf diese Weise wird immer DB1 für Live und DB2 für jede Staging-Arbeit verwendet.