Size: a a a

SqlCom.ru - Стиль жизни SQL

2020 November 23

O

Oleg T in SqlCom.ru - Стиль жизни SQL
Alexey
сигнатура брутфорса?
вы же не думаете, что он по SSH в сеть пролез в тапках и без какого-либо исполняемого кода?
источник

O

Oleg T in SqlCom.ru - Стиль жизни SQL
вот тут и суппорты и MVP отвечают одинаково на вопрос ставить ли AV на сервер БД:
https://social.technet.microsoft.com/Forums/ie/ru-RU/aa6a3326-f388-4282-872a-86c9f7f8cfef/sql-server-antivirus?forum=databasedesign
источник

IC

Igor Chizhov in SqlCom.ru - Стиль жизни SQL
Коллеги, поделитесь опытом плиз.
Была БД 100 Гб, в один прекрасный момент в поле nvarchar(max) одной таблицы записалось порядка 500 Гб данных.
Сейчас потребность в этих данных отпала, далее в таких полях будет храниться не более 50 Гб. Общий объем занятого места вряд ли превысит 150-200 Гб. Текущий размер mdf более 600 Гб.

Вопроса ровно два:
1. Может ли очистка данного поля привести к существенной фрагментации БД и потере быстродействия? На тесте фрагментация таблицы остаётся приемлемой после очистки.
2. Стоит ли запланировать сжатие mdf, с учетом проблемы фрагментации индексов?
источник

O

Oleg T in SqlCom.ru - Стиль жизни SQL
Igor Chizhov
Коллеги, поделитесь опытом плиз.
Была БД 100 Гб, в один прекрасный момент в поле nvarchar(max) одной таблицы записалось порядка 500 Гб данных.
Сейчас потребность в этих данных отпала, далее в таких полях будет храниться не более 50 Гб. Общий объем занятого места вряд ли превысит 150-200 Гб. Текущий размер mdf более 600 Гб.

Вопроса ровно два:
1. Может ли очистка данного поля привести к существенной фрагментации БД и потере быстродействия? На тесте фрагментация таблицы остаётся приемлемой после очистки.
2. Стоит ли запланировать сжатие mdf, с учетом проблемы фрагментации индексов?
1. 500 Гб в одно поле - My Deepest respect. Это круто.
2. Очистка не приведен к фрагментации сама по себе. ну будут дырки там, где некогда были данные. Это не фрагментация как таковая в терминах СУБД. ФРагментация будет, если вы выполните шринк файла и не выполните после него перестройку индексов в БД. Я бы советовал сделать и то и другое, уменьшив БД до размеров, которых БД может достичь в пределах года, т.е. не выжимая всё место до капли, пусть будет небольшой запас внутри.
источник

O

Oleg T in SqlCom.ru - Стиль жизни SQL
Igor Chizhov
Коллеги, поделитесь опытом плиз.
Была БД 100 Гб, в один прекрасный момент в поле nvarchar(max) одной таблицы записалось порядка 500 Гб данных.
Сейчас потребность в этих данных отпала, далее в таких полях будет храниться не более 50 Гб. Общий объем занятого места вряд ли превысит 150-200 Гб. Текущий размер mdf более 600 Гб.

Вопроса ровно два:
1. Может ли очистка данного поля привести к существенной фрагментации БД и потере быстродействия? На тесте фрагментация таблицы остаётся приемлемой после очистки.
2. Стоит ли запланировать сжатие mdf, с учетом проблемы фрагментации индексов?
Btw, это MSSQL? Filestream не рассматривали?
источник

IC

Igor Chizhov in SqlCom.ru - Стиль жизни SQL
Да, это MS. 500Гб не в одну строку конечно, порядка 15000 записей. Всегда было по несколько Мб, доработка + косяк разрабов приложения, выжили с трудом. Вынесение в Filestream рассматривается на перспективу.
источник

В

Вячеслав in SqlCom.ru - Стиль жизни SQL
для полей больше мегабайта микрософты уже рекомендуют использовать Filestream емнип
источник

IC

Igor Chizhov in SqlCom.ru - Стиль жизни SQL
Такое досталось по наследству )
источник

O

Oleg T in SqlCom.ru - Стиль жизни SQL
В файлстрим можно вынести прозрачно. поддержку на стороне софта уже потом прикрутить можно.
источник

К

Какой-то Хмырь... in SqlCom.ru - Стиль жизни SQL
Igor Chizhov
Коллеги, поделитесь опытом плиз.
Была БД 100 Гб, в один прекрасный момент в поле nvarchar(max) одной таблицы записалось порядка 500 Гб данных.
Сейчас потребность в этих данных отпала, далее в таких полях будет храниться не более 50 Гб. Общий объем занятого места вряд ли превысит 150-200 Гб. Текущий размер mdf более 600 Гб.

Вопроса ровно два:
1. Может ли очистка данного поля привести к существенной фрагментации БД и потере быстродействия? На тесте фрагментация таблицы остаётся приемлемой после очистки.
2. Стоит ли запланировать сжатие mdf, с учетом проблемы фрагментации индексов?
Да как тут уже выясняли, фрагментация не так уж страшна.
источник

К

Какой-то Хмырь... in SqlCom.ru - Стиль жизни SQL
Не тому ответил
источник

O

Oleg T in SqlCom.ru - Стиль жизни SQL
Какой-то Хмырь
Да как тут уже выясняли, фрагментация не так уж страшна.
поделитесь выкладками пожалуйста. я не застал.
источник

IC

Igor Chizhov in SqlCom.ru - Стиль жизни SQL
Какой-то Хмырь
Не тому ответил
Почему, я же спрашивал )
источник

IC

Igor Chizhov in SqlCom.ru - Стиль жизни SQL
На тесте всё норм, но там и нагрузка околонулевая
источник

К

Какой-то Хмырь... in SqlCom.ru - Стиль жизни SQL
Igor Chizhov
Почему, я же спрашивал )
Так я сначала Олегу ответил
источник

IC

Igor Chizhov in SqlCom.ru - Стиль жизни SQL
Хуже не будет точно )
источник

IC

Igor Chizhov in SqlCom.ru - Стиль жизни SQL
Какой-то Хмырь
Так я сначала Олегу ответил
А, понял )
источник

К

Какой-то Хмырь... in SqlCom.ru - Стиль жизни SQL
Oleg T
поделитесь выкладками пожалуйста. я не застал.
Ща поищу, но не обещаю
источник

O

Oleg T in SqlCom.ru - Стиль жизни SQL
Какой-то Хмырь
Ща поищу, но не обещаю
благодарю.
источник

IC

Igor Chizhov in SqlCom.ru - Стиль жизни SQL
Oleg T
В файлстрим можно вынести прозрачно. поддержку на стороне софта уже потом прикрутить можно.
Опыта не было, но посмотрю в эту сторону
источник