Log Shipping не позволяет работать во второй базе т.к. она доступна только на чтения. Кроме того организация Log Shipping и его поддержка это немного сложнее, чем эпизодическое восстановление из резервных копий.
Восстановление на конкретный момент времени, это скорее доп. фишка, но тоже весомая. Тут главное восстановление на максимально актуальный момент времени. И тут что бы понять Простая или Полная модель вам нужна задайте главный вопрос: за какой период мы можем себе позволить потерять данные? За 15 минут, за 2 часа, за 1 день?
Если толкового ответа получить не у кого, то попытайтесь просчитать последствия сами. Сколько народу вводят данные одновременно? реально ли будет ввести данные повторно, например за день или только с обеда? есть ли другие системы с которыми обменивается ваша БД и будут ли работать обмен, если вы откатите БД? и т.п.
AlwaysOn — это кончено замечательно. Но к сожалению не каждая организация может себе позволить иметь резервный сервер, и тем более DBA в штате. Также AlwaysOn не отменяет бэкапы.
Не могу согласиться. Вопрос все-таки был немного другой. Основные модели восстановления это Полная и Простая. И с точки зрения производительности БД один одинаковы, т.к. в обоих случаях ведется журнал транзакций, только при Простой модели он усекается автоматически. Что касается модель восстановления с неполным протоколированием (Bulk Logged), то эта модель предназначена для временной замены Полной модели на период проведения массовых операций, например, массовой вставки данных или перестроением индексов.
На данный момент из коробки не умеет. Но это легко сделать в программе с помощью скрипта, например Powershell. Возможно в следующей статье я напишу как это сделать. Также есть в планах добавить эту функциональность в коробочное решение.
Какие у вас планы в развитии этого продукта?
Планы развивать в сторону оптимизации производительности баз данных. На многих БД остаются настройки по дефолту, что также сказывается на производительности. Мы планируем сделать так чтобы программа предлагала и могла поменять эти настройки на более оптимальные. Кроме этого, рассматриваются планы по расширению функционала в части аудита SQL Server: например, если пользователь хочет узнать причины снижения производительности, то включив опцию в программе он сможет собрать информацию со счетчиков SQL Server и отправить нам для анализа. Мы проанализируем результаты и подготовим для него отчет с рекомендациями. Главное чтобы это было просто для пользователя.
А как по вашему выглядит ваша ЦА? Фирма держит сервера с кучей БД у себя в офисе, но не имеет вменяемого IT-отдела или хотя бы специалиста?
Целевая аудитория — это компания любого масштаба в которой используется SQL Server. Как правило в компаниях есть свой ИТ отдел, но нет администратора баз данных владеющего специфическими знаниями. Небольшие компании иногда приглашают ИТ специалиста на аутсорсе. Баз может быть много, до нескольких десятков. Но как правило они не большие (до 50-80 Гб). Про все это было написано в статье. К сказанному я бы добавил, что у ИТ должно быть желание и стремление, настроить все надежно и качественно, а не просто JOB с бэкапом для галочки и собственного утешения.
Так-как по моему для хоть сколько-то серьезного продакшена процессы обслуживания\оптимизации БД и процессы создания и хранения резервных копий баз стоит разделять, или я не прав?
Резервное копирование и остальное обслуживание (проверка целостности, обслуживание индексов и т.п.) это составные части общего процесса обслуживания баз данных. Есть определенная последовательность в которой рекомендуется выполнять эти процедуры. Например, полный бэкап лучше делать после проверки целостности БД и процедур обслуживания индексов. Так Вы будете знать, что целостность резервной копии в порядке и следующая разностная резервная копия будет меньшего объема. И конечно процедуры не должны пересекаться. Другими словами, это должен быть единый и продуманный процесс обслуживания.
Пригласить живого DBA это конечно хорошо. Но как показывает практика — не приглашают. Подозреваю, что причины следующие:
1. В круге знакомых просто нет таких спецов, а стоимость услуг сторонних компаний будет далеко не 100$
2. Нет необходимости в живом DBA — либо базы данных не большие, либо нагрузка не велика. Оно и так пока работает…
очередные GUI-костыли (которые и так уже встроены в MSSQL, где для ленивых всё «кодится» драг-н-дропом блоков со стрелочками и заданием параметров блоков)
Все верно вы пишите — механизм встроен (кроме Express версии) и «кодится» все и драг-анд-дроп работает. Но надо знать как кодить, знать интерфейс, понимать последовательность задач, стратегию резервного копирование и много, много ещё чего. Также нужно чтобы это все удобно мониторилось впоследствии. Иначе просто потом «забьешь».
И чем ваш продукт лучше чем MSSCDPM или Veeam Backup? Ну кроме ценника?
Указанные вами продукты в основном для бэкапирования и восстановления. Они не закрывают вопросы обслуживания баз SQL Server.
И как-то странно выходит, «невольный» DBA не способен осилить настройку штатных средств бэкапа MS SQL, но при этом способен разбираться/писать сам скрипты через Ваше GUI на PS, VBS и т.д.?
Возможность писать скрипты — это скорее опция для продвинутых и тем, кому это необходимо. Большинству пользователей хватает 5-10 минутной настройки. Опять же вынужден заметить, речь не только по бэкапы.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Если толкового ответа получить не у кого, то попытайтесь просчитать последствия сами. Сколько народу вводят данные одновременно? реально ли будет ввести данные повторно, например за день или только с обеда? есть ли другие системы с которыми обменивается ваша БД и будут ли работать обмен, если вы откатите БД? и т.п.
Усечение не влияет на производительность. По крайней мере так, чтобы это заметили пользователи.
На данный момент из коробки не умеет. Но это легко сделать в программе с помощью скрипта, например Powershell. Возможно в следующей статье я напишу как это сделать. Также есть в планах добавить эту функциональность в коробочное решение.
Планы развивать в сторону оптимизации производительности баз данных. На многих БД остаются настройки по дефолту, что также сказывается на производительности. Мы планируем сделать так чтобы программа предлагала и могла поменять эти настройки на более оптимальные. Кроме этого, рассматриваются планы по расширению функционала в части аудита SQL Server: например, если пользователь хочет узнать причины снижения производительности, то включив опцию в программе он сможет собрать информацию со счетчиков SQL Server и отправить нам для анализа. Мы проанализируем результаты и подготовим для него отчет с рекомендациями. Главное чтобы это было просто для пользователя.
Целевая аудитория — это компания любого масштаба в которой используется SQL Server. Как правило в компаниях есть свой ИТ отдел, но нет администратора баз данных владеющего специфическими знаниями. Небольшие компании иногда приглашают ИТ специалиста на аутсорсе. Баз может быть много, до нескольких десятков. Но как правило они не большие (до 50-80 Гб). Про все это было написано в статье. К сказанному я бы добавил, что у ИТ должно быть желание и стремление, настроить все надежно и качественно, а не просто JOB с бэкапом для галочки и собственного утешения.
Резервное копирование и остальное обслуживание (проверка целостности, обслуживание индексов и т.п.) это составные части общего процесса обслуживания баз данных. Есть определенная последовательность в которой рекомендуется выполнять эти процедуры. Например, полный бэкап лучше делать после проверки целостности БД и процедур обслуживания индексов. Так Вы будете знать, что целостность резервной копии в порядке и следующая разностная резервная копия будет меньшего объема. И конечно процедуры не должны пересекаться. Другими словами, это должен быть единый и продуманный процесс обслуживания.
Извините не очень понял, что вы хотели сказать
Функционал и настройка показаны в видео. Собственно, софт и делался, чтобы не парится с настройкой.
Пригласить живого DBA это конечно хорошо. Но как показывает практика — не приглашают. Подозреваю, что причины следующие:
1. В круге знакомых просто нет таких спецов, а стоимость услуг сторонних компаний будет далеко не 100$
2. Нет необходимости в живом DBA — либо базы данных не большие, либо нагрузка не велика. Оно и так пока работает…
Все верно вы пишите — механизм встроен (кроме Express версии) и «кодится» все и драг-анд-дроп работает. Но надо знать как кодить, знать интерфейс, понимать последовательность задач, стратегию резервного копирование и много, много ещё чего. Также нужно чтобы это все удобно мониторилось впоследствии. Иначе просто потом «забьешь».
Указанные вами продукты в основном для бэкапирования и восстановления. Они не закрывают вопросы обслуживания баз SQL Server.
Возможность писать скрипты — это скорее опция для продвинутых и тем, кому это необходимо. Большинству пользователей хватает 5-10 минутной настройки. Опять же вынужден заметить, речь не только по бэкапы.