Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Обслуживание большой БД  [new]
AlexanderVS
Member

Откуда: Krasnoyarsk
Сообщений: 433
Существуют ли какие то рекомендации по обслуживанию БД достаточно больших размеров (800Гб и более)?
В настоящее время все данные и индексы храниться в единственной файловой группе.
Есть ли смысл выделить самую большую таблицу (10% от общего размера и 560 млн.строк) в отдельную файловую группу?
На базе настроен Log Shipping. Версия MS SQL 2014 (x64).
9 янв 17, 05:45    [20083470]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
aleks2
Guest
С такими вопросами, совет один: "работает - не трогай".
9 янв 17, 06:18    [20083474]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
AlexanderVS
В настоящее время все данные и индексы храниться в единственной файловой группе.
Есть ли смысл выделить самую большую таблицу (10% от общего размера и 560 млн.строк) в отдельную файловую группу?
Это вопрос не про обслуживание, а про структуру файлгрупп и файлов.
Смысла в выделении такой отдельной файлгруппы нет.
9 янв 17, 10:04    [20083735]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
AlexanderVS
Member

Откуда: Krasnoyarsk
Сообщений: 433
alexeyvg,
Спасибо.
Конечно вопрос получился корявым, я даже не файлгруппы имел ввиду, а просто вторичный файл данных.
9 янв 17, 10:27    [20083807]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
AlexanderVS
alexeyvg,
Спасибо.
Конечно вопрос получился корявым, я даже не файлгруппы имел ввиду, а просто вторичный файл данных.
Таблицу нельзя положить во "вторичный файл данных".
Вообще, нет такого понятия "вторичный файл данных". Вы можете для файлгруппы указать несколько файлов, и сиквел сам будет неким образом распределять данные по этим нескольким файлам.
Такое делают, если у вас есть несколько отдельных устройств (например, RAID-массивов), и вы хотите по ним распределить нагрузку.
Конечно, для микро-баз (800Гб) этого делать не надо.
Ещё рекомендуется делать несколько файлов для базы tempdb, но тоже, если она достаточно большая и интенсивно используемая (на этот счёт есть специальные рекомендации от MS).
9 янв 17, 10:58    [20083933]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
AlexanderVS
Member

Откуда: Krasnoyarsk
Сообщений: 433
alexeyvg,
Термин "вторичный файл данных" я взял на [url=]https://technet.microsoft.com/ru-ru/library/ms179316(v=sql.105).aspx[/url], возможно не корректный перевод.
С основными понятиями вроде "Такое делают, если у вас есть несколько отдельных устройств" - я даже уже знаком, но все равно спасибо.
Просто я не предполагал, что 800Гб - это микро-база :).
9 янв 17, 11:45    [20084149]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
AlexanderVS
Термин "вторичный файл данных" я взял на [url=]https://technet.microsoft.com/ru-ru/library/ms179316(v=sql.105).aspx[/url], возможно не корректный перевод.
Да, с термином я погорячился :-)
Но всё равно, для данных это же неважно. Данные делятся пользователем по файлгруппам, а уже внутри файлгруппы, по файлам, сиквел делит их сам.

AlexanderVS
Просто я не предполагал, что 800Гб - это микро-база :).
Ну как, железки же сейчас мощные. MS сейчас не рассматривает базы до петабайта как особо большие :-)

Такие размеры можно хранить на зеркале, ну или в крайнем случае на одном рейде. Городить множество массивов, и вручную распределять базу такого размера по ним - перебор. А разбивать базу на много файлов, к тому же вручную по файлгруппам, если у вас один массив, тоже не имеет смысла (кроме tempdb)

Разве что для некоторых случаев управления секционированными таблицами, но, во первых, это выходит за рамки исходного вопроса, во вторых, секционирование с отдельными фалгруппами для базы в 800Гб - тоже некоторый перебор (хотя в каких то случаях и может оказаться полезно).
9 янв 17, 12:00    [20084248]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
AlexanderVS
Member

Откуда: Krasnoyarsk
Сообщений: 433
alexeyvg,
Раз уж у нас получилась дискуссия (спасибо Вам за это), то рискну высказать свое мнение по поводу того, почему я подумал про создание отдельной файлгруппы (тут я немного запутался про файлгруппы и файлы внутри них) и вынесение туда таблицы (или нескольких таблиц), ну или отдельных индексов - поскольку серверная платформа, на которой установлен MS SQL, все же многопроцессорная (2 Xeona по 4 ядра) - ты мы можем распараллелить файловый Ввод/Вывод, ведь именно поэтому есть рекомендации создавать несколько фалов для tempdb?
В качестве хранилища у нас используетcя IBM DS3500, где собран RAID10 (на 10 дисках) для данных и RAID1 - для журнала.
9 янв 17, 12:31    [20084389]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37068
AlexanderVS
alexeyvg,
Раз уж у нас получилась дискуссия (спасибо Вам за это), то рискну высказать свое мнение по поводу того, почему я подумал про создание отдельной файлгруппы (тут я немного запутался про файлгруппы и файлы внутри них) и вынесение туда таблицы (или нескольких таблиц), ну или отдельных индексов - поскольку серверная платформа, на которой установлен MS SQL, все же многопроцессорная (2 Xeona по 4 ядра) - ты мы можем распараллелить файловый Ввод/Вывод, ведь именно поэтому есть рекомендации создавать несколько фалов для tempdb?
В качестве хранилища у нас используетcя IBM DS3500, где собран RAID10 (на 10 дисках) для данных и RAID1 - для журнала.
Рейд-контроллеру все равно, сколько виндовых потоков напихало ему запросы ввода-вывода в его очередь.

Рекомендация делать несколько файлов tempdb возникла из-за того, что бывали проблемы с доступом к нескольким определенным страницам файла, и эти проблемы не были связаны с производительностью дисковой подсистемы.
9 янв 17, 12:43    [20084446]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
o-o
Guest
AlexanderVS
...мы можем распараллелить файловый Ввод/Вывод, ведь именно поэтому есть рекомендации создавать несколько фалов для tempdb?

нет
The Accidental DBA (Day 27 of 30): Troubleshooting: Tempdb Contention
Randal
Tempdb contention refers to a bottleneck for threads
trying to access allocation pages that are in-memory; it has nothing to do with I/O
.

Consider the scenario of hundreds of concurrent queries that all create, use, and then drop small temporary tables (that by their very nature are always stored in tempdb). Each time a temp table is created, a data page must be allocated, plus an allocation metadata page to keep track of the data pages allocated to the table. This requires making a note in an allocation page (called a PFS page – see here for in-depth info) that those two pages have been allocated in the database. When the temp table is dropped, those pages are deallocated, and they must be marked as such in that PFS page again. Only one thread at a time can be changing the allocation page, making it a hotspot and slowing down the overall workload.

There are three things you can do to alleviate this kind of contention and increase the throughput of the overall workload:

1. Stop using temp tables
2. Enable trace flag 1118 as a start-up trace flag
3. Create multiple tempdb data files

#3 will help to remove the PFS page contention, by spreading the allocation workload over multiple files, thus reducing contention on the individual, per-file PFS pages.

в темпдб кучу таблиц одновременно пытаются разместить,
это не ваш случай
9 янв 17, 12:53    [20084485]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
AlexanderVS
Member

Откуда: Krasnoyarsk
Сообщений: 433
o-o
AlexanderVS
...мы можем распараллелить файловый Ввод/Вывод, ведь именно поэтому есть рекомендации создавать несколько фалов для tempdb?

нет
The Accidental DBA (Day 27 of 30): Troubleshooting: Tempdb Contention
в темпдб кучу таблиц одновременно пытаются разместить,
это не ваш случай

Понял.
9 янв 17, 12:57    [20084505]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
Eleanor
Member

Откуда:
Сообщений: 2925
AlexanderVS,

Одно из применений файловых групп - это восстановление только части БД на Ent\Dev версиях Sql Server.
Можно этим пользоваться, если места на диске мало \ хочется быстро увидеть нужную информацию.
Может быть вам пригодится.
9 янв 17, 13:25    [20084601]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10730
Блог
В тему:
Много файлов данных для tempdb нужно из-за конкуренции за PFS и для повышения производительности ввода-вывода при промежуточной материализации. Для больших БД (от 3Тб) лучше использовать SSD.
Создавая любую базу данных - никогда не размещайте пользовательские объекты в файловой группе PRIMARY. Создавайте для своих объектов другие группы и делайте дефолтными наиболее популярные.
Для большой БД может понадобиться несколько дисковых массивов для размещения файлов данных - это будет обуславливаться вашими требованиями производительности и/или времени отклика. Сейчас уже дешевле сразу класть данные OLTP на SSD - не нужно будет управлять множеством массивов и будет занимать меньше места в стойке. Если используйте очереди, то файлы PRIMARY тоже лучше разместить на SSD.
9 янв 17, 14:07    [20084720]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Александр Гладченко
Создавая любую базу данных - никогда не размещайте пользовательские объекты в файловой группе PRIMARY. Создавайте для своих объектов другие группы и делайте дефолтными наиболее популярные.
А это рекомендации МС, или какие то исследования?
Не слышал о таком... Приходит в голову разве что то, что держать системные объекты в файле, где не будет интенсивной нагрузки, немного безопаснее, меньше вероятность их повреждения.
9 янв 17, 16:42    [20085459]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
Александр Гладченко
В тему:
Много файлов данных для tempdb нужно из-за конкуренции за PFS и для повышения производительности ввода-вывода при промежуточной материализации. Для больших БД (от 3Тб) лучше использовать SSD.
Создавая любую базу данных - никогда не размещайте пользовательские объекты в файловой группе PRIMARY. Создавайте для своих объектов другие группы и делайте дефолтными наиболее популярные.
Для большой БД может понадобиться несколько дисковых массивов для размещения файлов данных - это будет обуславливаться вашими требованиями производительности и/или времени отклика. Сейчас уже дешевле сразу класть данные OLTP на SSD - не нужно будет управлять множеством массивов и будет занимать меньше места в стойке. Если используйте очереди, то файлы PRIMARY тоже лучше разместить на SSD.


Во времена 2005-го рекомендовали выделать индексы в отдельную файловую группу от данных и класть её на отдельный диск. Актуальная ли такая рекомендация сейчас?
9 янв 17, 19:12    [20086017]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37068
a_voronin
Во времена 2005-го рекомендовали выделать индексы в отдельную файловую группу от данных и класть её на отдельный диск. Актуальная ли такая рекомендация сейчас?
Такая же странная рекомендация, как, скажем, отключать параллелизм: кому-то поможет, кому-то нет.
9 янв 17, 19:17    [20086033]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
AlexanderVS
Member

Откуда: Krasnoyarsk
Сообщений: 433
Александр Гладченко
В тему:
Много файлов данных для tempdb нужно из-за конкуренции за PFS и для повышения производительности ввода-вывода при промежуточной материализации. Для больших БД (от 3Тб) лучше использовать SSD.
Создавая любую базу данных - никогда не размещайте пользовательские объекты в файловой группе PRIMARY. Создавайте для своих объектов другие группы и делайте дефолтными наиболее популярные.
Для большой БД может понадобиться несколько дисковых массивов для размещения файлов данных - это будет обуславливаться вашими требованиями производительности и/или времени отклика. Сейчас уже дешевле сразу класть данные OLTP на SSD - не нужно будет управлять множеством массивов и будет занимать меньше места в стойке. Если используйте очереди, то файлы PRIMARY тоже лучше разместить на SSD.

А SSD использовать просто в зеркале или есть смысл собрать из них тот же RAID10?
Например, имеем 6 шт. SSD 600Гб-800Гб, установленных во что то, типа StorWaze V3700. Можно сделать 3 RAID1 и разместить на них 3 файлгруппы или же 1 RAID10 и держать там все? Нужно ли думать об отдельном физическом устройстве, в данном случае, для журнала транзакций? Просто тема использования SSD дисков для размещения на них БД - для меня совсем новая.
10 янв 17, 04:32    [20087250]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
982183
Member

Откуда: VL
Сообщений: 3357
aleks2
С такими вопросами, совет один: "работает - не трогай".

ПОКА работает
10 янв 17, 05:22    [20087258]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
AlexanderVS
А SSD использовать просто в зеркале или есть смысл собрать из них тот же RAID10?
Например, имеем 6 шт. SSD 600Гб-800Гб, установленных во что то, типа StorWaze V3700. Можно сделать 3 RAID1 и разместить на них 3 файлгруппы или же 1 RAID10 и держать там все? Нужно ли думать об отдельном физическом устройстве, в данном случае, для журнала транзакций? Просто тема использования SSD дисков для размещения на них БД - для меня совсем новая.
Журнал транзакций нужно разместить на отдельном зеркале.
А файлы данных - как вам будет удобнее всем этим управлять. Лучше RAID10 сделать, что бы не заморачиваться с управлением файлгруппами и файлами.
AlexanderVS
установленных во что то, типа StorWaze V3700
СХД - зло :-)
10 янв 17, 09:12    [20087479]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
8 ядер - это small office, даже в голову не берите диски потому, что в них не упрётесь.
10 янв 17, 17:11    [20090360]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
ghkj
Guest
alexeyvg
Александр Гладченко
Создавая любую базу данных - никогда не размещайте пользовательские объекты в файловой группе PRIMARY. Создавайте для своих объектов другие группы и делайте дефолтными наиболее популярные.
А это рекомендации МС, или какие то исследования?
Не слышал о таком... Приходит в голову разве что то, что держать системные объекты в файле, где не будет интенсивной нагрузки, немного безопаснее, меньше вероятность их повреждения.

+ любой fg можно в online переместить на другой диск, кроме primary
10 янв 17, 17:16    [20090387]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Владислав Колосов
8 ядер - это small office, даже в голову не берите диски потому, что в них не упрётесь.
Обычно бывает по другому. Обычно упирается в диски, и обычно они дороже процессоров.
10 дисков на ядро вообще было MS-рекомендацией для сбалансированного сервера (конечно, для HDD).
Сейчас, в связи с удешевлением ядер, можно скорректировать, но всё равно дисков нужно много, и они по прежнему дороже процессоров.
10 янв 17, 18:09    [20090660]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
o-o
Guest
ghkj
+ любой fg можно в online переместить на другой диск, кроме primary

группы перемещать нельзя,
можно перемещать файлы.
но и как перемещать файлы, не отправляя их в оффлайн,
все равно непонятно.
или это про рестор отдельных файлов с перемещением
без отправки базы в оффлайн?
тогда это куча ограничений:
это полная модель (простая + ридонли) + энтерпрайз.
а ведь Гладченко написал
автор
Создавая любую базу данных - никогда не размещайте пользовательские объекты в файловой группе PRIMARY

как я понимаю, alexeyvg спросил именно для всех баз зачем
10 янв 17, 18:42    [20090762]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
ghkj
Guest
o-o,

под перемещением fg в online я имел ввиду создание в той же fg второго файла на другом диске
и вытеснение всех данных из первого файла во второй с помощью dbcc shrinkfile
с последующим удалением первого файла.
10 янв 17, 22:47    [20091547]     Ответить | Цитировать Сообщить модератору
 Re: Обслуживание большой БД  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37068
ghkj
o-o,

под перемещением fg в online я имел ввиду создание в той же fg второго файла на другом диске
и вытеснение всех данных из первого файла во второй с помощью dbcc shrinkfile
с последующим удалением первого файла.
Эта возможность малоприменима к более-менее значимой файловой группе в рамках "большой БД".
11 янв 17, 01:35    [20091950]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить