ALTER DATABASE, veritabanına bir kilit yerleştirilemediğinden başarısız oldu


124

Veritabanını yeniden başlatmam gerekiyor çünkü bazı işlemler çalışmıyor. Planım, onu çevrimdışı duruma getirmek ve tekrar çevrimiçi hale getirmek.

Bunu Sql Server Management Studio 2008'de yapmaya çalışıyorum:

use master;
go
alter database qcvalues
set single_user
with rollback immediate;
alter database qcvalues
set multi_user;
go

Şu hataları alıyorum:

Msg 5061, Level 16, State 1, Line 1
ALTER DATABASE failed because a lock could not be placed on database 'qcvalues'. Try again later.
Msg 5069, Level 16, State 1, Line 1
ALTER DATABASE statement failed.
Msg 5061, Level 16, State 1, Line 4
ALTER DATABASE failed because a lock could not be placed on database 'qcvalues'. Try again later.
Msg 5069, Level 16, State 1, Line 4
ALTER DATABASE statement failed.

Neyi yanlış yapıyorum?


İlk etapta bu ihtiyaca neden olan sorun nedir? Şu anda bazı geri alma işlemleriniz var mı? Ayrıca bu komutu halen açık olabilecek başka bir SSMS penceresinde çalıştırdınız mı? Merak ediyorum (saf spekülasyon) bunun diğer girişimleri engelleyen bir kilit alıp almayacağını merak ediyorum, ancak veritabanının aslında single_user moduna geçirilmesinden önce hala bekliyor.
Martin Smith

1
@Martin - yeterince adil. Başka bir şey düşünmem veya aklımı kaybetmem gerekiyor. bunlardan biri oldukça mümkün
codingbadger

@ Herkese çok teşekkür ederim, SSMS'yi yeniden başlattım ve herkesi öldürebildim
JOE SKEET

Akıllı olabilir. Veritabanına erişmeye çalışan dalgalı satırları olan tamamlanmamış bir sorguyu sildim ve sonra çalıştı.
Faahmed

Yanıtlar:


293

Hatayı aldıktan sonra çalıştırın

EXEC sp_who2

Listede veritabanını arayın. Bir bağlantının sonlandırılmamış olması mümkündür. Veritabanına herhangi bir bağlantı bulursanız,

KILL <SPID>

<SPID>veritabanına bağlı oturumlar için SPID nerede .

Veritabanına yapılan tüm bağlantılar kaldırıldıktan sonra komut dosyanızı deneyin.

Maalesef, sorunu görmenizin bir nedeni yok, ancak burada sorunun başka bir yerde meydana geldiğini gösteren bir bağlantı var.

http://www.geakeit.co.uk/2010/12/11/sql-take-offline-fails-alter-database-failed-because-a-lock-could-not-error-5061/


Bir bağlantının komut tarafından neden sonlandırılmayacağına dair herhangi bir açıklama yapabilir misiniz? Düşünebilmemin tek nedeni, hala geri dönme sürecinde olması veya set single_userhala beklemede olan bir girişim olmasıdır.
Martin Smith

@Martin, korkarım bunun için bir sebebim yok. Ancak, başkalarının sorunu gördüğünü gösteren bir bağlantı ekleyeceğim. İşlem geri dönüşünün sorun olabileceğini kabul ediyorum, ancak KILLbu da çözmez.
bobs

Bunun neden olduğunu anlamak güzel, ancak bağlantınızdaki yorumlar işe yarayacağını gösteriyor gibi görünüyor! (+1)
Martin Smith

KILL (87) sonuç Msg 102, Level 15, State 1, Line 1 Incorrect syntax near '('.erm ....
Tim Abell

2
@MartinSmith Sanırım nedenini biliyorum: Aynı problemi yaşadım, sp_who2 altında görünen kalıcı bir bağlantı, çevrimdışının durmasına neden oluyor. Ssms'de açık bir düzenleme satır penceresi olduğu ortaya çıktı. Burada olanın satır düzenleme penceresinin düzenlenebilir bir sonuç kümesiyle açık tutulan bir sorgu olduğuna inanıyorum. SQL Server, güncelleme ifadelerine alternatif olarak böyle bir özelliğe sahiptir. Bu belirli ssms penceresi kapatıldığında, askıya alma işlemi çevrimdışı olarak tamamlandı.
John

5

Aşağıdakileri yaparak bu hatayı yeniden oluşturmayı başardım.

Bağlantı 1 (birkaç dakika açık bırakın)

CREATE DATABASE TESTING123
GO

USE TESTING123;

SELECT NEWID() AS X INTO FOO
FROM sys.objects s1,sys.objects s2,sys.objects s3,sys.objects s4 ,sys.objects s5 ,sys.objects s6

Bağlantı 2 ve 3

set lock_timeout 5;

ALTER DATABASE TESTING123 SET SINGLE_USER WITH ROLLBACK IMMEDIATE;


1

Birinin benim kadar şanslı olması durumunda bunu buraya ekleyeceğim.

Sp_who2 süreç listesini incelerken, sadece etkilenen veritabanı için değil aynı zamanda master için de çalışan süreçlere dikkat edin . Benim durumumda, veritabanını engelleyen sorun, xp_cmdshell başlatan bir saklı yordamla ilgiliydi.

Ana veritabanı için KILL / RollBack durumunda herhangi bir işleminiz olup olmadığını kontrol edin

SELECT *
FROM sys.sysprocesses
WHERE cmd = 'KILLED/ROLLBACK'

Aynı sorunu yaşıyorsanız, sadece KILL komutu muhtemelen yardımcı olmayacaktır. SQL sunucusunu yeniden başlatabilir veya daha iyi bir yol, SQL sunucu işletim sisteminde Windows işlemleri altında cmd.exe'yi bulup öldürmektir.


0

SQL Management Studio'da, Güvenlik -> Girişler'e gidin ve Oturum Açma'ya çift tıklayın. Sol sütundan Sunucu Rollerini seçin ve sysadmin'in işaretlendiğini doğrulayın.

Benim durumumda, bu ayrıcalığa sahip olmayan bir hesapla giriş yaptım.

HTH!


1
Orijinal sorudaki hata, SA olduğunuzda da meydana gelir, haklarınızla hiçbir ilgisi yoktur. Yeterli haklara sahip değilseniz, çevrimdışı komutu yürütemezsiniz.
Abel

0

İşlem kimliğini öldürmek benim için iyi çalıştı. "EXEC sp_who2" komutunu yeni bir sorgu penceresi üzerinden çalıştırırken ... ve "meşgul" veritabanı için sonuçları filtreleyerek, "KILL" komutuyla işlemleri öldürmek hile yapmayı başardı. Bundan sonra her şey tekrar çalıştı.


0

Sadece iki sentimi eklemek için. Beyanı başarılı bir şekilde çalıştırmak için bir db girişinin gerekli minimum ayrıcalıklarını ararken kendimi de aynı duruma soktum:

ALTER DATABASE ... SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Görünüşe göre ALTER deyimi , bir sysadmin oturum açma ile çalıştırıldığında başarıyla tamamlanıyor , ancak aşağıdaki gibi "yalnızca" sınırlı izinlere sahip bir oturum açma altında yürütüldüğünde bağlantı temizleme bölümünü gerektiriyor:

ALTER ANY DATABASE

Not: "ALTER VERİTABANI .." dbcreator rolü + HERHANGİ BİR VERİTABANI ayrıcalıklarına sahip bir oturum açma altında çalıştırıldığında neden çalışmadığını anlamaya çalışmak için saatler harcadım . İşte MSDN iş parçacığım !


0

Bunun eski bir gönderi olduğunu biliyorum ama son zamanlarda çok benzer bir sorunla karşılaştım. Maalesef, özel bir kilit yerleştirilemediğinden, alter veritabanı komutlarından hiçbirini kullanamadım. Ancak db ile hiçbir zaman açık bir bağlantı bulamadım. Sonunda veritabanının sağlık durumunu, onu kurtarma yerine geri yükleme durumuna zorlamak için zorla silmem gerekti.


0

Nadir durumlarda (örneğin, yoğun bir işlem gerçekleştirildikten sonra), veritabanı dosyasında bir FILE kilidi tutan çalışan bir CHECKPOINT sistem işlemi MULTI_USER moduna geçişi engeller.


0

Benim senaryomda, sp_who2 altında veritabanını engelleyen bir işlem yoktu. Bununla birlikte, veritabanı diğer veritabanlarımızdan çok daha büyük olduğu için bekleyen işlemlerin hala çalışmakta olduğunu keşfettik ve bu nedenle, duraklatılmış veritabanına sağ tıklayarak 'verileri devam ettirmeyi' denedikten sonra kullanılabilirlik grubu altındaki veritabanı hala kırmızı / çevrimdışı olarak görüntüleniyor.

Hala çalışan işlemler olup olmadığını kontrol etmek için sadece şu komutu çalıştırın: yüzde_complete> 0 olan sys.dm_exec_requests içinden tamamlanma yüzdesini seçin

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.