Sqlserver
 sql >> база данни >  >> RDS >> Sqlserver

ROLLBACK TRUNCATE в SQL Server

Случвало ли ви се е случайно да изпълните TRUNCATE команда на грешна маса? Това ще доведе до загуба на всички данни. Най-лошото е, че няма да имате шанс да си върнете данните. В тази статия ще разгледаме как да избегнем подобни ситуации и да имаме шанс да ОТКРИВАМЕ ОТСЪЩАНЕ .

Не можете да ОТКРИВАТЕ ОТСЪЩАНЕ

Просто не можете да върнете обратно транзакция, ако тя вече е ангажирана, но можете да направите нещо друго, за да върнете данните обратно (или поне някои части от тях).

Когато изпълните TRUNCATE изявление, вашите данни все още са в MDF файла. Той обаче не се вижда, защото SQL Server третира това като свободно пространство (ОТРЕЗИ казва на SQL Server да освободи страници с данни).

Единственият начин да получите обратно данните е по някакъв начин да прочетете освободените страници с данни и да ги конвертирате в четими данни.

Трябва да действате бързо, защото свободното пространство ще бъде презаписано с нови данни, ако вече не е така. Ако можете да спрете своя екземпляр на SQL Server и да направите копие на MDF и LDF файлове, това ще ви спечели повече време.

Има някои инструменти, които могат да направят този вид възстановяване.

Можете да ОТРЕЖАТЕ ОТСЪЩАНЕ

ОТСЪРЗВАНЕ е регистрирана операция, но SQL Server не регистрира всеки отделен ред, тъй като отрязва таблицата. SQL Server регистрира само факта, че TRUNCATE операцията се случи. Той също така регистрира информацията за страниците и екстентите, които са били освободени. Има обаче достатъчно информация за връщане назад, като просто преразпределите тези страници. Архивното копие на регистрационните файлове се нуждае само от информацията, която е ОТРЕЗВАНЕ НА ТАБЛИЦАТА се случи. За да възстановите ОТРЕЗВАНЕ НА ТАБЛИЦА , операцията просто се прилага отново. Включените данни не са необходими по време на ВЪЗСТАНОВЯВАНЕ (както би било за истинска „минимално регистрирана“ операция като ОБЪВЪРНЕНО ВМЕСВАНЕ ).

SQL Server знае кои страници са принадлежали на таблицата, доколкото са заключени с ексклузивно заключване и както всички X заключване, те се задържат до края на транзакцията. Ето защо страниците или екстентите не могат да бъдат освободени и със сигурност не могат да бъдат използвани повторно.

Ето един пример:

Имаме брой от 504 реда и няколко страници. Сега ще разгледаме броя на редовете и страниците, които принадлежат на таблицата.

BEGIN TRAN
TRUNCATE TABLE dbo.Products;
SELECT COUNT(*) FROM dbo.Products;
 
DBCC IND('AdventureWorks', 'Products', -1);
DBCC EXTENTINFO('AdventureWorks', 'Products', -1);
 
SELECT resource_type, resource_description,
        request_mode FROM sys.dm_tran_locks
WHERE  resource_type IN ('EXTENT', 'PAGE')
AND   resource_database_id = DB_ID('AdventureWorks');

Няма да видите редове от DBCC IND и 0 реда от count(*). Информацията за ключалките връща следното:

resource_type resource_description request_mode
————- ———————————
EXTENT 1:33352 X
PAGE 1:42486 X
EXTENT 1:42488 X
СТРАНИЦА 1:42487 X
СТРАНИЦА 1:42488 X
СТРАНИЦА 1:42489 X
СТРАНИЦА 1:23027 X
СТРАНИЦА 1:23030 X
СТРАНИЦА 1:23029 X
PAGE 1:26992 X
PAGE 1:26993 X

Степента и заключванията на страници включват всички страници, които видяхме в DBCC IND изход. Само след като се ОТМЕНЯТ транзакцията ще бъде освободена от ключалките и трябва да видите отново всички редове и страници в таблицата.

ROLLBACK TRAN;
GO
SELECT COUNT(*) FROM dbo.Products;
DBCC IND('AdventureWorks', 'Products', -1);
GO

Бъдете внимателни и винаги обгръщайте оператора на таблицата TRUNCATE в транзакцията.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Защо EF генерира SQL заявки с ненужни нулеви проверки?

  2. Съкратете всички таблици в база данни в SQL Server - SQL Server / TSQL урок, част 55

  3. SQL актуализация с row_number()

  4. Дефинирайте стъпките за курсора на SQL Server - SQL Server / TSQL урок

  5. Оптимизация на SQL заявки:Най-добри практики за подобрена производителност