Ну во первых удобнее работать, добавили базу, она «подхватилась»
Во вторых проще контролировать выполнение
В третьих сразу следить за достаточным кол-вом копий и удаляет уже не нужные архивы
В четвертых у вас одно задание для всего
Всё это можно сделать и в планах обслуживания, но для этого придется потрудится, я пояснял в статье, что данное решение именно для неподготовленных особо пользователей, работающее «из коробки», реализованное стандартными средствами и работающее пожалуй на всех версиях с 2000 SQL точно (если убрать сжатие)
Этот велосипед надо собрать в кучу и настроить, а теперь возьмите и посмотрите на половине предприятий с серьезными продуктами администрирование находится в зачаточном состоянии
Софт умеет работать напрямую с сотовым модемом, или как вариант email to sms gate от любого сотового оператора, но с ними как правило качество не очень и задержки большие доставки
Я вам не говорил об алгоритмах под мощное железо, я говорил об обычной практике, что заниматься нужно именно грамотной разработкой а не тратить время на выделение массы времени на решения, которые в продакшене и не должны возникать то… Это выглядит как вечное спасение системы
Вопрос в том что не zabbix используется, а http://www.activexperts.com/, с ним приходится немного кустарненько, ну и не хочется городить в БД объекты… потому в одну строку для него так сделано.
Результатом изменения состояния я имею СМС/письмо и вижу что не так
DECLARE @MINSIZE INT = 20; -- минимальное место на диске
DECLARE @RESULT VARCHAR(200) = '';
SELECT @RESULT = @RESULT + CASE
WHEN (available_bytes / 1024 / 1024 / 1024) > @MINSIZE
THEN ''
ELSE volume_mount_point + '=' + CAST(available_bytes / 1024 / 1024 / 1024 AS VARCHAR) + ' GB Free'
END + ' '
FROM sys.master_files AS f
CROSS APPLY sys.dm_os_volume_stats(f.database_id, f.file_id)
GROUP BY volume_mount_point, total_bytes, available_bytes;
SELECT CASE WHEN LTRIM(RTRIM(@RESULT))='' THEN 'OK' ELSE @RESULT END as RESULT
в итоге получаю результат в виде все «ОК» или список дисков, на которых место меньше порога указанного в @MINSIZE
Мы ушли от темы, мы говорим об индексах или проектировании хранилищ Бд? А что не так с Бд размером скажем 500 Гб, сети гигабитные давно, дисковые массивы работают на Гигабайтных скоростях. Бугвально неделю назад видел скорость чтения на массиве 1 ГБАЙТ в секунду на не большем таком предприятии. Я все же склонен говорить о сбалансированных системах с точки зрения ресурсов и потребностей. Собственно если мы пытаемся на десктопном железе решить задачи масштаба среднего предприятия, ну простите, как это относится к статье? А вообще экономия сомнительна на таких системах… Посчитайте ФОТ специалистов для поддержания работоспособности хотя бы за год и вы поймёте, что лучше вложиться даже в очень хорошее железо… Я уж не говорю про качество работы систем «на грани» и про простои предприятия… Выбор должен быть разумен…
Эти все условия должны были быть добавлены в теги, иначе м ы говорим просто об MS SQL и подразумеваем что понимаем как использовать и какие ресурсы под какие системы
Предлагаю добавить тогда к статье теги, слабое железо. Речь ведь шла не про оптимизацию работы на слабом железе а про оптимизацию индексов, если вы занимаетесь такими вопросами сейчас, то ваша система будет требовать постоянной оптимизации. А следовательно стоимость владения её будет не соизмерима с вложением в железо. Стоимость месяца работы DBA покроет все затраты на разовую покупку железа и настройку и забыть на ближайшие пару лет…
Я не говорю что стоит железом решать вопрос, но выбор должен быть разумен…
Немного в текущем контексте — это не то что милисекунды, это микросекунды. Вы мне говорите же о деградации реальной, а не о теоретической. В вашем случае вопрос лишь стоит о качестве селективнлсти индексов… Ни какой деградации при достаточном кол-ве ресурсов у вас не будет. Конечно, если у вас дисковые сортировки для выполнения таких запросов или обновление по пол таблицы не происходит, но согласитесь что это уже не нормально
Не могу согласится, поясните, как влияет изменение первой сотни или последней сотни строк в таблице на производительность даже если в ней миллионы строк?
Мы говорим не про смысл, возможно процесс этого требует, вопрос в другом, как технически отличается изменение в любом из прошлых периодов?
Или вы под хранилищем подразумеваете перенос в другие файловые группы и секционирование?
Деградация производительности и вслески нагрузки (зависания) легко отслеживается мониторингом, если к вам с такой проблемой пришёл пользователь, то пора систему подвергать серьезному анализу…
Возможно везло). Не сильно понимаю ограничения на редактирование, оно ни как не влияет на производительность и стараюсь не проектировать таких систем. Только если это не связано с особенностями бизнес-процесса
Во вторых проще контролировать выполнение
В третьих сразу следить за достаточным кол-вом копий и удаляет уже не нужные архивы
В четвертых у вас одно задание для всего
Всё это можно сделать и в планах обслуживания, но для этого придется потрудится, я пояснял в статье, что данное решение именно для неподготовленных особо пользователей, работающее «из коробки», реализованное стандартными средствами и работающее пожалуй на всех версиях с 2000 SQL точно (если убрать сжатие)
Результатом изменения состояния я имею СМС/письмо и вижу что не так
в итоге получаю результат в виде все «ОК» или список дисков, на которых место меньше порога указанного в @MINSIZE
Я не говорю что стоит железом решать вопрос, но выбор должен быть разумен…
Или вы перешли на конкретную Бд и сейчас говорите о пересчете регистров, то это совсем из другой оперы
Мы говорим не про смысл, возможно процесс этого требует, вопрос в другом, как технически отличается изменение в любом из прошлых периодов?
Или вы под хранилищем подразумеваете перенос в другие файловые группы и секционирование?