Rozmiar właściwości nie jest dostępny dla bazy danych

Niedawno przywróciłem bazę danych do tego samego wystąpienia, z którego została utworzona kopia zapasowa (SQL Server 2008 R2 Enterprise) i okazało się, że nie mogę uzyskać dostępu do właściwości bazy danych.

Zrobiłem następujące:

• Sprawdzono, czy właściciel bazy danych został poprawnie ustawiony za pomocą sp_helpdb.
• Zmieniono właściciela bazy danych na sa. To nie jest poprawka.
• Zmieniłem właściciela bazy danych z powrotem na mojego sysadminużytkownika. To nie jest poprawka.
• Wystawione DBCC updateusageprzeciwko dotkniętej bazie danych. To nie jest poprawka.
• Uruchom DBCC CheckDBprzywróconą kopię do innej instancji. Nie znaleziono korupcji. Przywrócona kopia (z tego samego pliku kopii zapasowej) nie zgłosiła żadnych błędów podczas uzyskiwania dostępu do okna właściwości bazy danych.

Czy ktoś może pomóc?

Komunikat o błędzie, który pojawia się podczas próby wyświetlenia właściwości, to:

Nie można wyświetlić żądanego okna dialogowego. (SqlMgmt)
Rozmiar właściwości nie jest dostępny dla bazy danych „[DBNAME]”.
Ta właściwość może nie istnieć dla tego obiektu lub może nie być możliwa do odzyskania z powodu niewystarczających praw dostępu. (Microsoft.SqlServer.Smo)

Jestem sysadminw tym przypadku.

Aktualizacja: Zgodnie z sugestią utworzyłem nowego użytkownika, nadałem mu nazwę sysadmin i zmieniłem na niego właściciela bazy danych. Niestety nie jest to poprawka. Zobaczę, czy ślad profilera przyniesie coś użytecznego.

Aktualizacja: Aaron - pierwotna nazwa bazy danych została zmieniona i przeniesiona do trybu offline, ale nadal jest w tej instancji. Kopia zapasowa tej bazy danych została następnie przywrócona przy użyciu oryginalnej nazwy. Nazwy plików nowych plików bazy danych różnią się od oryginału, ponieważ znajdują się w tym samym folderze, co oryginalny plik mdf / ldf. Przywrócona baza danych obsługuje obecnie nasze krytyczne aplikacje jak zwykle.

Rozwiązałem to przez ponowne uruchomienie usługi SQL Server, niestety / na szczęście.

Mój początkowy pomysł polegał na odłączeniu / dołączeniu bazy danych. Nie dlatego, że myślałem, że to naprawi problem, po prostu przeczytałem to gdzieś na forum. To nie miało wpływu.

Niestety nie zrobiłem tego, co sugerował PJ Mahoney: prowadzenie śladu. Mam nadzieję, że ponownie zobaczę ten problem, aby dowiedzieć się, czy ślad coś odkryje. Dzieki za sugestie.

Przynajmniej odpowiedź na moje pytanie oznacza, że ​​nie muszę widzieć kolejnej sugestii dotyczącej zmiany właściciela bazy danych; P

Dzięki

Miałem ten sam błąd podczas próby zmodyfikowania właściwości wzrostu pliku pliku dziennika produkcyjnej bazy danych. Próbowałem użyć SSMS i miałem ten sam błąd:

Rozmiar właściwości nie jest dostępny dla bazy danych XXX.

Zamiast tego użyłem T-SQL do modyfikacji pliku dziennika bazy danych.

USE [master]
GO
ALTER DATABASE [MyDatabase] MODIFY FILE ( NAME = N'MyDatabase_log', FILEGROWTH = 524288KB )
GO

Po zakończeniu polecenia mogłem otworzyć właściwości bazy danych w SSMS. Mam nadzieję, że to zadziała dla innych.

Może się to zdarzyć w bardzo zajętych bazach danych, a nawet jeśli baza danych ogólnie nie jest zajęta, ale w tej chwili wykonuje instrukcję, która szybko zmienia rozmiar pliku dziennika. Na przykład, jeśli spróbujesz usunąć bardzo dużą liczbę wierszy (milionów) z tabeli, silnik będzie musiał zalogować każdy wiersz w celu wycofania, co zmusi plik dziennika do szybkiego wzrostu. Podczas gdy jest to w toku, jeśli spróbujesz otworzyć właściwości bazy danych w SSMS, zobaczysz komunikat o błędzie „rozmiar właściwości nie jest dostępny ..”

Innym sposobem na odtworzenie tego jest: weź bardzo dużą bazę danych (ponad 100 milionów wierszy) i wykonaj na niej instrukcję ALTER TABLE (np. Przekonwertuj kolumnę char na varchar). Zobacz, jak plik dziennika wysadza w powietrze gigantyczne megabajty, a nawet gigabajty na sekundę. Ponownie, gdy tak się dzieje, SSMS nie będzie w stanie podać rozmiaru bazy danych, ponieważ zmienia się zbyt szybko, aby był dokładny.

Nie trzeba dodawać, że nie próbuj tego na serwerach na żywo. :)

Właśnie natrafiłem na to i ze śladu, najwyraźniej został on zablokowany przez działającą operację ODBUDOWYWANIA INDEKSU

Mój konkretny błąd to

Właściwość SpaceAvailable nie jest dostępna dla bazy danych „[dbOverwatch]”. Ta właściwość może nie istnieć dla tego obiektu lub może nie być możliwa do odzyskania z powodu niewystarczających praw dostępu. (Microsoft.SqlServer.Smo)

SELECT
(SELECT SUM(CAST(df.size as float)) FROM sys.database_files AS df WHERE df.type in ( 0, 2, 4 ) ) AS [DbSize],
(SUM(a.total_pages) + (SELECT ISNULL(SUM(CAST(df.size as bigint)), 0) FROM sys.database_files AS df WHERE df.type = 2 )) AS [SpaceUsed]
FROM
sys.partitions p join sys.allocation_units a on p.partition_id = a.container_id left join sys.internal_tables it on p.object_id = it.object_id

Musi mieć bardzo niską wartość limitu czasu, ale być może możesz sprawdzić, czy coś blokuje się podczas próby uzyskania dostępu do właściwości

Otrzymuję ten komunikat o błędzie podczas wdrażania rozwiązania bazy danych SQL Server przeciwko bazie danych (w SQL Server 2008 R2). Po zakończeniu wdrażania błąd zniknął. Jest to trochę nieprzyjemne, ponieważ DB nie jest w trybie pojedynczego użytkownika ani tylko do odczytu (oczywiście nie) ani nic innego wskazującego przyczynę.