uaggsterчеловек_ниоткуда1) проверка целостности БД
Не нужна если БД на СХД или RAID с проверкой целостности.
Гм... Это как? Что означает "с проверкой целостности"?
RAID5/1/10 и т.д.?
Так они могут писать "мимо" - только в путь! Какая-нибудь бяка в драйвере контроллера, и всё, понеслось!
(Дада. Я люблю сервера DEPO, куда деваться то).
человек_ниоткуда Не поможет если после проверки булет выполнено резервное копирование БД.
Ну, первым шагом джоба DBCC CHECKDB, вторым (если не обломилось на первом шаге) - полный бэкап (ну, например).
Если база, скажем так, сотня-другая гигабайт - то всё за вполне себе небольшое время завершается.
Почему нет то?

Законно...
Мой косяк что бекап после. Сначала бекап, потом checkdb. Ибо лучше сделать бекап и ждать CHECKDB если всё упадёт до бекапа, то будет нехорошо.
Если в БД случился косяк, то случиться он в момент, когда запись произведена. А выявится, когда страница данных (с косяком) будет прочитана. Я, признаться, не помню как работает механизм checksum страницы: конкретно не знаю проверяет SQL checksum в момент сброса буффера на диск или нет. Ибо если проверяет, то получается, в момент когда произойдёт ошибка - база и так в suspend уйдёт; получается что вообще нет смысла checkdb делать, за исключением случая когда диск такой конченый, что буквально сыпется от вращения блина. А если не проверяет (что я считаю вполне правильно), то CHECKDB нужен перед удалением последнего исторического бекапа, т.е. намного реже чем сам бекап. И он вообще не нужен если бекапы проверяются тестовыми ресторами.
CHECKDB это полный скан всей базы, т.е. как-никак да диск это напрягает - и ресурс его сокращает.

тогда так:
Можно, если есть время на выполнение этой процедуры. Иначе менять дисковую систему на обеспечивающую большую надёжность.


uaggsterчеловек_ниоткуда Не очень нужна для GPT-партиций (вопрос спорный).

Почему? Объясните, правда не понимаю!

GPT как я понял по описанию в себе имеет механизм контроля целостности данных. Т.е. она поймёт, если в неё что-то нитак записалось сама. Но, опять же, вопрос спорный - мож я что-то в мануале перекурил ;) буду рад достоверной инфе, если неправ.

IvanIvan481) проверяю целостность БД
Если хочешь и есть время.

IvanIvan482) обновляю статистику
ДА! И да: делай sp_updatestats. Для начала этого достаточно. Раз в два часа.

IvanIvan483) делаю шринк
Только transaction log (ldf).

IvanIvan484) бэкаплю
так?

Нет! :) Бекапишь сразу после CHECKDB. Или CHECKDB перед бекапом.
Т.е. (2) - (3) - (1) - (4) или (1) - (4) - (2) - (3)
IvanIvan48еще по t-sql
тут все верно по скриптам или как-то не так? а то sql сказал что он мол не отвечает за последствия предоставленного им кода)))

IvanIvan481) проверяю целостность БД
/chesk.sql
USE [mytest001]
GO
DBCC CHECKDB(N'mytest001') WITH NO_INFOMSGS

Норм

IvanIvan482) обновляю статистику
/stat.sql
use [mybase123]
GO
UPDATE STATISTICS [dbo].[Table_1]
WITH FULLSCAN

Не совсем. Делай через sp_updatestats раз в два часа.


IvanIvan483)
/shrink.sql
USE [mytest001]
GO
DBCC SHRINKDATABASE (mytest001, TRUNCATEONLY)

НЕТ!
Делай только :



И проверь чтоб лог был только один.





IvanIvan484)
/backup.sql
BACKUP DATABASE [mybase123] TO DISK = N'C:\script\BASE\mybase' WITH RETAINDAYS = 3, NOFORMAT, INIT, NAME = N'mybase123_backup_2017_05_24_234900_4553030', SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 10
GO
declare @backupSetId as int
select @backupSetId = position from msdb..backupset where database_name=N'mybase123' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'mybase123' )
if @backupSetId is null begin raiserror(N'Ошибка верификации. Сведения о резервном копировании для базы данных "mybase123" не найдены.', 16, 1) end
RESTORE VERIFYONLY FROM DISK = N'C:\script\BASE\mybase' WITH FILE = @backupSetId, NOUNLOAD, NOREWIND

"RESTORE VERIFYONLY" делает почти ничего... хорошо хорошо, он делает проверку, но она не гарантирует что БД из бекапа восстановится... И раз уж делаете DBCC CHECKDB - то смысла в этом ещё меньше. Я считаю что уж лучше делать полный рестор в новую бд - и если он не упал, то всё ок.

Гавриленко Сергей Алексеевиччеловек_ниоткуда,

Не НАДО советовать шринковать лог. Потому что при его приращении будет полная ж..па:
человек_ниоткуда6) очистка журнала
shrink? -- SHRINK нужен до того размера при котором не произойдёт вырастание журнала в рабочее время.

Гавриленко Сергей АлексеевичНахрена вообще сервер заставлять делать бесполезную работу сначала по расширению файла, потом по его сжатию?
Ну идёт maintenance ночной - лог вырастает; начался день - лог маленький, и работает с меньшими latency. Не во всех случаях это даёт прирост производительности - но хуже от этого точно не будет. Если вы способны пообщаться без эмоций, я готов рассказать поподробнее об этом в отдельной теме.
Топикастеру надо организовать maintenance, а не в спецы по SQL-у записываться вообщето. Я даю рекомендации общего пользования.

Кстати помниться кто-то из крутых блоггеров рекомендовал вот это: https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html Это скрипт обновления статистик и перестройки индексов в одном флаконе. IvanIvan48 тебе для пункта (2) это.

[quot o-o]человек_ниоткудаЕсли в БД случился косяк, то случиться он в момент, когда запись произведена. А выявится, когда страница данных (с косяком) будет прочитана. CHECKDB нужен перед удалением последнего исторического бекапа, т.е. намного реже чем сам бекап. И он вообще не нужен если бекапы проверяются тестовыми ресторами.

Так понятнее, братюнь?

o-oкаша полнейшая.
Эээй... Без нервов, дружище. Всё хорошо.

o-o... пропущено
особо нервные могут не читать, чтобы не перевозбуждаться
Отлично выступили, молодой человек.

На разумную часть вашей тирады, посоветовался с коллегами, почитал. brent советует делать checkdb, коллеги в целом склоняются к мнению, что на хорошем железе это не нужно.
Стоит подумать, спасибо.

Всем возражающим - за 10 лет ниразу не видел проблем которые решает checkdb на хорошем железе. Если вы видели, хорошо, буду иметь ввиду. Попробую свои проды проверить на досуге.

IvanIvan48По какой причине сначало надо бэкапить, а потом уже проверять базу? Просто ну для меня это не логично) при проверке происходит запись в эту же базу что ли?
Бекапить нужно чтоб был бекап! Чтоб если железо упадёт пока делается checkdb - можно было восстановиться.
В идеале нужно сделать бекап >> развернуть его не тестовой среде >> сделать полученной БД (на тесте) checkdb.