Yedekliliği kontrol etmek için tabloları düşürmeden gizlemek / devre dışı bırakmak nasıl?


12

Korumak ve webservice yöntemleri ve artık kullanılmayan veritabanı tabloları içeren eski bir eski sistemi genişletmek zorunda. Tabloların gerçekten gereksiz olduğundan tamamen emin olmadığım için onları düşürmekten korkuyorum.

Aynı etkiyi (tablolar artık kullanılamaz) düşürmeden elde etmenin başka bir yolu var mı? Benim fikrim onları Deletedgeçerli varsayılandan farklı bir şemaya (ör. ) Aktarmaktı dbo.

IF NOT EXISTS (SELECT * FROM sys.schemas WHERE name = 'Deleted')
BEGIN
   EXEC('CREATE SCHEMA Deleted')
END

ALTER SCHEMA Deleted TRANSFER dbo.TableName;

Başka bir seçenek var mı veya şema yaklaşımının dezavantajları var mı?

Yanıtlar:


7

Aynı şeyi (tablolar artık kullanılamaz) düşürmeden elde etmenin başka bir yolu var mı?

Şema değişikliği çok hızlı bir işlemdir - yalnızca meta veri değişikliği gerekir. Orijinal fikrim Aaron Bertrand'ın blogu Schema Switch-A-Roo'dan .

Şunlar arasından adımları izleyebilirsiniz burada Cevabıma

Açıkçası sp_rename N'old table ', N'new table' veya sadece tablo izinlerini reddetme gibi başka yöntemler de vardır .


Hangi cevabı kabul etmem gerektiğinden emin değildim çünkü hepsi faydalı. Aaron'ın makalesini bilmiyordum, bu yüzden daha fazla bilgi içerdiğinden (sadece bağlantılı olsa bile) bunu kabul ettim.
Tim Schmelter

@TimSchmelter Yararlı bulduğunuza sevindim. Makalenin veya cevabımın (bağlantılı) burada tekrarlanması mantıklı değil. Bu yüzden referans verdim.
Kin Shah

12

Diğer birkaç seçenek yalnızca tabloları yeniden adlandırmaktır veya kümelenmiş dizinleri varsa, kümelenmiş dizini devre dışı bırakabilirsiniz.


Teşekkürler. Kümelenmiş bir dizini devre dışı bırakmanın tabloyu kullanılamaz hale getirdiğini bilmiyordum. Bu yaklaşımların artıları ve eksileri nelerdir (+ şema)?
Tim Schmelter

5
@TimSchmelter, CI'yi devre dışı bırakmanın bir con'unu, tekrar etkinleştirmek için dizini yeniden oluşturmanız gerektiğidir. Diğer bir seçenek de, veritabanı sahibi veya sistem yöneticileri hala onları görecek ve muhtemelen sahiplik zincirleme yoluyla tablodaki izinleri genel rol için reddetmektir.
Martin Smith

Bir tabloyu bırakmadan veya bir tablodan bir sütun bırakmadan önce, genellikle adın sonuna "_deprecated" veya benzeri bir şey ekleyerek yeniden adlandırırım. O zaman hata yoksa, referans veren hiçbir şey olmamalıdır.
Jay

İzin değişiklikleri şanslıdır. Bir uygulamayı çalıştıran hizmet hesabı dbo veya daha da kötüsü sysadmin ise, herhangi bir DENY türünü tamamen göz ardı edecektir. Umarım değildir, ama olur.
Kenneth Fisher

6

Tablodaki izinleri , [kullanabilecekleri] Rollerden / Gruplardan / Hesaplardan kaldırın .

Bir şey patlarsa, onları [çabucak] geri koyun.

İpucu: Bu değişiklikleri yapmak için bir komut dosyası kullanmak gerçekten çok iyi bir fikir olacaktır.


Üretim dışı bir veritabanında test etme gibi. ;) Umarım, bu OP için açıktı.
jpmc26

@ jpmc26. İlk önce üretim dışı bir veritabanında test edeceğim. Ancak sorun, işlevlerin veya veritabanı nesnelerinin dışarıdan kullanılıp kullanılmadığını bilmek istememdir (sadece web hizmet yöntemleri ile değil, aynı zamanda doğrudan şirketin diğer yerlerindeki veritabanı veya yönetici araçlarında).
Tim Schmelter

Hm. DBA'lar tarafından doğrudan DB erişimi arıyorsanız, günlük kaydı yapmak gibi görünüyor. El ile yapılan çalışmadan eşyada ve eşyasızda aynı kullanımı görmeniz pek olası olmayabilir. Bu işlemleri günlüğe kaydetmenin ne kadar kolay olacağından emin değilim, ancak bir oturum açma ürününüz varsa, kullanımları aramak için analiz edebilirsiniz.
jpmc26

@ jpmc26: Bu yöneticiler yüzlerine düşerse sorun değil. Müşteriler için sorun değil, ancak piyasaya sürülmeden önce test sisteminde kontrol edilebilir.
Tim Schmelter

3

İzinleri kaldırmak genellikle işe yaramaz çünkü birisinin izinleri olmadığından BELİRSİNİZ. Muhtemelen bir grup aracılığıyla, rol ya da hatta sistemadmin oldukları için (umarım olmasın).

Tablolar için bunları devre dışı bırakabilirsiniz. Ve bu hızlı bir süreç. Ancak, bunları etkinleştirmek için onları yeniden oluşturmanızı ve oldukça uzun sürebilen büyük bir tabloyu gerektirir.

En iyi seçeneğiniz, nesneyi yeni bir şemaya (önerdiğiniz gibi) taşımak veya nesneyi yeniden adlandırmak olacaktır. Bu işlemlerin her ikisi de hem yapmak hem de geri almak hızlı ve kolaydır. İzinler her iki yönde de yerinde kalacaktır.

Uygulayabileceğiniz ek bir adım , nesnenin genişletilmiş özelliklerine bir "TBD notu" eklemektir . Değişikliği ne zaman yaptığınızı ve / veya kurtulmak için neden güvenli olduğunuzu düşündüğünüz notları not edebilirsiniz.

Bütün bunlar, kullanılan tüm nesnelerin bulunduğundan emin olmak için birkaç gün boyunca genişletilmiş etkinlikler oturumu (veya profiler izleme) çalıştıracağımı söyledi. Oturumu yalnızca nesne adıyla ve ek yükü azaltmak için dokunduğunuzda büyük ölçüde sınırlandırabilirsiniz. Ayrıca, her ayın olduğundan emin olmak için bu oturumu ayın iki tarafında ve hatta çeyrek sonunda bile birkaç gün boyunca çalıştırdığınızdan emin olun.


3

Phil W.'nin önerdiği gibi izinleri kaldırın.

Ayrıca, tabloları kullanan tüm saklı yordamların izinlerini kaldırın. SQL Server'da, (diğerlerini bilmiyorum) izinler çağıran bir nesneden (örneğin saklı yordam) çağrılan nesneye (örneğin bir tablo) zincirlenir.


Görev, bu tablolara erişmeye çalışan tüm araçların, işlevlerin, nesnelerin, sorguların (uzak veritabanlarında bile) başarısız olmasına izin vermekti. Saklı bir yordamı değiştirmek zorunda zaten ben bunu kullanmak bilmek zorunda. Yoksa bir tablonun saklı yordam tarafından kullanıldığını belirlemenin basit bir yolu var mı?
Tim Schmelter

Saklı yordamın değiştirilmesini önermedim, yalnızca EXECUTE iznini kaldırarak. Dediğiniz gibi, gerekirse izni geri yüklemek kolaydır. Saklanan yordam tarafından hangi tabloların kullanıldığını görebilirsiniz: SQL Server Management Studio, Nesne Gezgini'nde veritabanınızı seçin -> Programlanabilirlik -> Saklı Yordamlar. Bir sproc adına sağ tıklayın ve Bağımlılıkları Görüntüle'yi seçin. [Sproc name] öğesinin bağlı olduğu Nesneler'i seçin.
Peter Bill
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.