Skema Switch-A-Roo :Bagian 2

Metadata bebek-bebek-angsa

Masalah dengan kolom identitas dan batasan tampaknya tidak menjadi masalah besar. Meskipun objek *tampaknya* menunjuk ke objek yang salah menurut tampilan katalog, fungsionalitas – setidaknya untuk sisipan dasar – beroperasi seperti yang Anda harapkan jika Anda belum pernah melihat metadata.

Masalah besar adalah dengan pemicu – lupa sejenak betapa sepele saya membuat contoh ini, di dunia nyata, mungkin referensi tabel dasar dengan skema dan nama. Dalam hal ini, ketika dilampirkan ke meja yang salah, semuanya bisa berjalan ... yah, salah. Mari beralih kembali:

BEGIN TRANSACTION;
  ALTER SCHEMA holder TRANSFER prep.t1;
  ALTER SCHEMA prep   TRANSFER live.t1;
  ALTER SCHEMA live   TRANSFER holder.t1;
COMMIT TRANSACTION;

(Anda dapat menjalankan kueri metadata lagi untuk meyakinkan diri sendiri bahwa semuanya kembali normal.)

Sekarang mari kita ubah pemicunya *hanya* di live versi untuk benar-benar melakukan sesuatu yang berguna (yah, "berguna" dalam konteks eksperimen ini):

ALTER TRIGGER live.trig_live
ON live.t1
FOR INSERT
AS
BEGIN
  SELECT i.id, msg = 'live.trig'
    FROM inserted AS i 
    INNER JOIN live.t1 AS t 
    ON i.id = t.id;
END
GO

Sekarang mari kita sisipkan satu baris:

INSERT live.t1 DEFAULT VALUES;

Hasil:

id    msg
----  ----------
5     live.trig

Kemudian lakukan swap lagi:

BEGIN TRANSACTION;
  ALTER SCHEMA holder TRANSFER prep.t1;
  ALTER SCHEMA prep   TRANSFER live.t1;
  ALTER SCHEMA live   TRANSFER holder.t1;
COMMIT TRANSACTION;

Dan masukkan baris lain:

INSERT live.t1 DEFAULT VALUES;

Hasil (di panel pesan):

prep.trig

Uh oh. Jika kita melakukan pertukaran skema ini sekali dalam satu jam, maka selama 12 jam setiap hari, pemicunya tidak melakukan apa yang kita harapkan, karena ini terkait dengan salinan tabel yang salah! Sekarang mari kita ubah versi pemicu "persiapan":

ALTER TRIGGER prep.trig_prep
ON prep.t1
FOR INSERT
AS
BEGIN
  SELECT i.id, msg = 'prep.trig'
    FROM inserted AS i 
	INNER JOIN prep.t1 AS t 
	ON i.id = t.id;
END
GO

Hasil:

Yah, itu pasti tidak baik. Karena kita berada dalam fase metadata-is-swapped, tidak ada objek seperti itu; pemicunya sekarang live.trig_prep dan prep.trig_live . Bingung belum? Gerakan mengungkap kekerasan seksual demi menghapuskannya. Jadi mari kita coba ini:

EXEC sp_helptext 'live.trig_prep';

Hasil:

CREATE TRIGGER prep.trig_prep
ON prep.t1
FOR INSERT
AS
BEGIN
  PRINT 'prep.trig';
END

Nah, bukankah itu lucu? Bagaimana cara mengubah pemicu ini ketika metadatanya bahkan tidak tercermin dengan benar dalam definisinya sendiri? Mari kita coba ini:

ALTER TRIGGER live.trig_prep
ON prep.t1
FOR INSERT
AS
BEGIN
  SELECT i.id, msg = 'prep.trig'
    FROM inserted AS i 
    INNER JOIN prep.t1 AS t 
    ON i.id = t.id;
END
GO

Hasil:

Ini juga tidak baik, jelas. Tampaknya tidak ada cara yang baik untuk menyelesaikan skenario ini yang tidak melibatkan pertukaran objek kembali ke skema aslinya. Saya dapat mengubah pemicu ini menjadi melawan live.t1 :

ALTER TRIGGER live.trig_prep
ON live.t1
FOR INSERT
AS
BEGIN
  SELECT i.id, msg = 'live.trig'
    FROM inserted AS i 
    INNER JOIN live.t1 AS t 
    ON i.id = t.id;
END
GO

Tapi sekarang saya memiliki dua pemicu yang mengatakan, dalam teks isi mereka, bahwa mereka beroperasi melawan live.t1 , tetapi hanya yang ini yang benar-benar mengeksekusi. Ya, kepala saya berputar (dan begitu juga Michael J. Swart (@MJSwart) di posting blog ini). Dan perhatikan bahwa, untuk membersihkan kekacauan ini, setelah menukar skema kembali, saya dapat menghapus pemicu dengan nama aslinya:

DROP TRIGGER live.trig_live;
DROP TRIGGER prep.trig_prep;

Jika saya mencoba DROP TRIGGER live.trig_prep; , misalnya, saya mendapatkan kesalahan objek tidak ditemukan.

Resolusi?

Solusi untuk masalah pemicu adalah membuat CREATE TRIGGER secara dinamis kode, dan jatuhkan dan buat ulang pemicu, sebagai bagian dari swap. Pertama, mari kita kembalikan trigger ke tabel *saat ini* di live (Anda dapat memutuskan dalam skenario Anda jika Anda membutuhkan pemicu di prep versi tabel sama sekali):

CREATE TRIGGER live.trig_live
ON live.t1
FOR INSERT
AS
BEGIN
  SELECT i.id, msg = 'live.trig'
    FROM inserted AS i 
    INNER JOIN live.t1 AS t 
    ON i.id = t.id;
END
GO

Sekarang, contoh cepat tentang bagaimana skema swap baru kami akan bekerja (dan Anda mungkin harus menyesuaikan ini untuk menangani setiap pemicu, jika Anda memiliki beberapa pemicu, dan ulangi untuk skema di prep versi, jika Anda perlu mempertahankan pemicu di sana juga. Berhati-hatilah agar kode di bawah ini, untuk singkatnya, mengasumsikan bahwa hanya ada *satu* pemicu di live.t1 .

BEGIN TRANSACTION;
  DECLARE 
    @sql1 NVARCHAR(MAX),
    @sql2 NVARCHAR(MAX);
 
  SELECT 
    @sql1 = N'DROP TRIGGER live.' + QUOTENAME(name) + ';',
    @sql2 = OBJECT_DEFINITION([object_id])
  FROM sys.triggers
  WHERE [parent_id] = OBJECT_ID(N'live.t1');
 
  EXEC sp_executesql @sql1; -- drop the trigger before the transfer
 
  ALTER SCHEMA holder TRANSFER prep.t1;
  ALTER SCHEMA prep   TRANSFER live.t1;
  ALTER SCHEMA live   TRANSFER holder.t1;
 
  EXEC sp_executesql @sql2; -- re-create it after the transfer
COMMIT TRANSACTION;

Solusi lain (yang kurang diinginkan) adalah melakukan seluruh operasi pertukaran skema dua kali, termasuk operasi apa pun yang terjadi terhadap prep versi tabel. Yang sebagian besar mengalahkan tujuan pertukaran skema di tempat pertama:mengurangi waktu pengguna tidak dapat mengakses tabel dan memberi mereka data yang diperbarui dengan gangguan minimal.