Bir şema değişiminin nasıl gerçekleştiğini belirleme?

21

Dün kötü bir şey oldu.

Bir süre önce oluşturulmuş olan görünüm, nihayetinde raporları bozan biri tarafından değiştirildi. Ne yazık ki. birileri (bilerek veya bilmeyerek) PRODUCTION veritabanında bu değişikliği yaptı.

Sorum: Bu değişikliği kimin (kullanıcı adı) yaptığını bilmemizin bir yolu var (script / software / freeware etc), böylece bu kullanıcının üretim veritabanına erişimini iptal edebilirim.

Sorum açık değilse lütfen yorum yapın.

sql-server view

— xorpower
kaynak

36

Bu, etkin olduğu ve bu süre içinde devirilmediği sürece "Şema Değişiklik Geçmişi" raporunda görünmesi gerektiği için varsayılan izlemeye günlüğe kaydedilir.

Buna Management Studio’dan erişmek için veritabanına sağ tıklayın ardından içerik menüsünden Reports -> Standard Reports -> Schema Changes History

TSQL ile aynı bilgileri almak için kullanabilirsiniz.

SELECT StartTime
       ,LoginName
       --,f.*
FROM   sys.traces t
       CROSS APPLY fn_trace_gettable(REVERSE(SUBSTRING(REVERSE(t.path),
                                                       CHARINDEX('\', REVERSE(t.path)), 
                                                       260)
                                             ) + N'log.trc', DEFAULT) f
WHERE  t.is_default = 1
       AND ObjectName = 'FOO'
       AND EventClass IN (46, /*Object:Created*/
                          47, /*Object:Dropped*/
                          164 /*Object:Altered*/ )

— Martin Smith
kaynak

Teşekkürler Martin, 'FOO' yu benim görüşüme göre değiştirerek sorgu yaptım ama bu bir şey döndürmedi. Bunun neden olduğu hakkında bir fikrin var mı? Yine de sunucuda idam

— etmedim

1

@ Xorpower - Object:CreatedOlayı ele alması için değiştirdim. Sunucuda yürütmeyerek ne demek istediğinizi bilmiyor musunuz? Elbette doğru örneğe bağlı olmanız gerekir, ancak izinleriniz olduğu sürece bağlantının nereden geldiği önemli değildir.

— Martin Smith

Teşekkürler martin, ama sonuç hala aynı kalır

— xorpower 11

1

@ Xorpower - Aşağıdaki ne

— Martin Smith,

3

@ Xorpower - O zaman iz devrildi ve yaklaşık 11 saatten daha eski bir şeyin detaylarını kaybettiniz. Varsayılan izleme yalnızca 5 dosyayı tutar ve daha sonra eskileri siler. Sunucudaki dosya sistemini kontrol etmek isteyebilirsiniz, sadece bunu kontrol etmek için klasör kesinlikle böyledir. Klasör yolunu 11: SELECT path FROM sys.traces where is_default=1

— Martin Smith

19

Martin, zaten açık olan (açıkça devre dışı bırakılmadığı sürece), idari denetim izinin en iyi caddeye işaret etti. Eğer Yönetici izlemesinde bilgi bulamıyorum sen (devre dışı olduğunu veya geri dönüşümlü olan) olabilir günlük yedeklerden bilgi almak. Üretim DB'si olduğundan, periyodik tam yedekleme ve günlük yedekleriyle düzenli bir yedekleme döngüsünüz olduğunu varsayarım. Ayrı bir sunucuda veri tabanını olayın yakınına kadar geri yüklemeniz gerekecek, böylece DDL mevcut geri yüklenen kayıt defterinde olacak. O zaman fn_dblog()kütüğü kullanmak ve incelemek basit bir meseledir .

Bunun bir yolu, işlem başlama işlemlerine geçmektir:

select [Begin Time], [Transaction Name], [Transaction SID], * 
from fn_dblog(null, null)
where Operation = 'LOP_BEGIN_XACT';

Eğer ALTER VIEWbağımsız bir işlemle (yani BEGIN TRANSACTION/ ile çevrelenmemiş COMMIT) yayınlandıysa, o zaman adı verilen bir işleme başlayacaktır CreatProc transaction. Bunun için arayın ve [Transaction SID]istediğiniz kullanıcı adı SID'dir.

Başka bir olasılık da, istediğiniz görünümde bir SCH_M edinen işlemi aramaktır:

select [Lock Information], * 
from fn_dblog(null, null)
where [Lock Information] like '%' + cast(object_id('...') as varchar(10))+'%'
and [Lock Information] like '%LOCK_SCH_M%'
go

Görünümü DROP ve ardından CREATE ile değiştirdiyseniz, nesne kimliğinin büyük olasılıkla değiştirildiğini, ancak en azından CREATE (en son geri yüklenen db'deki görünümün geçerli nesne kimliği) olan CREATE işlemini gerçekleştireceğinizi unutmayın. İşlem kimliği ile geri dönün ve işlem başlangıç bilgisini alın:

select [Begin Time], [Transaction Name], [Transaction SID], *
from fn_dblog(null, null)
where [Transaction ID] = '...'
and Operation = 'LOP_BEGIN_XACT';

[İşlem SID] yine adamınız. SUSER_SNAMEOturum açma adını giriş SID'sinden almak için kullanın . SID 0x01 ise, giriş yapıldığı anlamına gelir; sabu, saşifreyi yapabileceğini bilen herhangi bir kişi anlamına gelir .

— Remus Rusanu
kaynak

2

Günlük dosyalarını okumak için güzel bir ipucu. Birisi varsayılan izleri devre dışı bıraktığında bu kullanışlı olur.

— StanleyJohns

İşlem SID'si null olursa ne olur?

— tahliye edildi

@evictednoise lütfen ilgili kayıtlarını kaydedin (ayrı bir soruda). Bir nedenden daha fazlası olabilir ve kayıt kayıtları gerçek nedeni belirlemeye yardımcı olur.

— Remus Rusanu

6

Hayır, bir DDL tetikleyicisi veya benzeri bir yöntemle oturum açmadıysanız

Bu veritabanında ALTER haklarına kimlerin veya sysadmin / db_owner / ddl_admin rolünün üyeliğine bakmak istiyorsunuz. Bu bir cadı avı yerine genel bir inceleme olarak daha iyi olurdu. Muhtemelen onaylanmamış ve yetkisiz değişiklikler yapma haklarına sahip başka insanlar da vardır.

— GBN
kaynak

0

Henüz yapmadıysanız, SQL Server Management Studio'da bulunan Şema Değişiklik Geçmişi raporunu incelemek isteyebilirsiniz . Görünüşe göre, SQL Server varsayılan olarak değişiklikleri kaydeder ( varsayılan izleme ) ve bu verileri bu rapor üzerinden görüntüleyebilmelisiniz. Talihsiz tek şey, bu izleme dosyalarının zaman geçtikçe otomatik olarak silinmesi / silinmesidir, bu nedenle veriler zaten tükenmiş olabilir. İyi şanslar!

— Mark Madej
kaynak

Boğmaca, boşver. Martin Smith'in cevabında bu rapora çoktan başvuru yaptığını gördüm. Bağlantıların herhangi birinin faydalı olması durumunda yine de bunu burada bırakacağım.

— Mark Madej