Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
dbnadm Member Откуда: Сообщений: 101 |
Ну есть такая рекомендация для tempdb добавлять файлов по кол-ву ядер типа для перфоманса. Понятно, что для этого дела есть заготовленный скриптец, так вот в очередной раз его накатывая я его поправил не везде где надо и в результате запустил вот такое: ALTER DATABASE tempdb ADD FILE (NAME = tempdev2, FILENAME = 'T:\TEMPDB\tempdb2.mdf', SIZE = 8MB, FILEGROWTH = 10%), ..... (NAME = tempdev12, FILENAME = 'T:\TEMPDB\tempdb12.mdf', SIZE = 8MB, FILEGROWTH = 10%), (NAME = tempdev10, FILENAME = 'T:\TEMPDB\tempdb13.mdf', SIZE = 8MB, FILEGROWTH = 10%), (NAME = tempdev10, FILENAME = 'T:\TEMPDB\tempdb14.mdf', SIZE = 8MB, FILEGROWTH = 10%), (NAME = tempdev10, FILENAME = 'T:\TEMPDB\tempdb15.mdf', SIZE = 8MB, FILEGROWTH = 10%) как видите в последних 3 строчках я правильно исправил физическое имя файла но логическое имя файла я пропустил и в результате оно оказалось ОДИНАКОВЫМ для 3 файлов. Удивительно то что эта команда отработала не о что без ошибок но даже без каких либо предупреждений. А вот после перезагрузки сервак уже лежал намертво с ошибкой: 2012-12-14 17:11:10.45 spid11s Clearing tempdb database. 2012-12-14 17:11:10.54 spid11s Starting up database 'tempdb'. 2012-12-14 17:11:11.08 spid11s Error: 1828, Severity: 16, State: 1. 2012-12-14 17:11:11.08 spid11s The logical file name "tempdev10" is already in use. Choose a different name. Так вот я не смог найти никакого способа починить это безобразие без переустановки SQL. Я пробовал всякие alter datbase modfy file/ remove file после запуска sql server -f, ничего не получилось. Сам синтаксис всех этих команд подразумевает что логическое имя файла уникально, а оно у меня уже не уникально, поэтому ни одна команда не работает. (Repair с инсталляционного диска тоже сбойнул, я не понял почему, разбираться уже влом, дело все равно видимо закончится просто переустановкой SQL Server.) Мне так кажется это просто бага какая-то, коллеги! Понятно что торопливость до добра не доводит, но не должен SQL Server попускать такую команду которая ложит сервак наглухо и потом нет никакого способа его починить. Поиск в Goggle отписания/солюшна подобной ситуевины не обнаружил. |
14 дек 12, 15:56 [13632897] Ответить | Цитировать Сообщить модератору |
Ozerov Member Откуда: Москва Сообщений: 3637 |
Нда уж, весело. А насчет по кол-ву ядер... Это что ж, мне 80 надо ставить (а если еще HP включить...) ? :) Не думаю, что тупо следовать это рекомендации есть гуд. Но это имхо! |
14 дек 12, 16:01 [13632952] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
Каждое ядро будет работать со своим файлом, никакого межядерного согласования владения ресурсами, тем более, что оно делается через файлы. |
||
14 дек 12, 16:20 [13633137] Ответить | Цитировать Сообщить модератору |
Ozerov Member Откуда: Москва Сообщений: 3637 |
Опять же, имхо, если есть затык по tempdb, то да. А если нет, изначально так делать - не вижу смысла... |
||||
14 дек 12, 16:23 [13633162] Ответить | Цитировать Сообщить модератору |
Crimean Member Откуда: Сообщений: 13148 |
если меня не подводит склероз, то в ранних версиях статьи было интересное уточнение, что типа таки да, оно бы неплохо по числу ядер, но делать надо без фанатизма - начните с 8 или с 10 файлов а там смотрите на поведение ну и внешнее проявление проблемы, когда нужно увеличивать число файлов вчера проскакивало - оно более чем характерно |
14 дек 12, 16:43 [13633322] Ответить | Цитировать Сообщить модератору |
Ozerov Member Откуда: Москва Сообщений: 3637 |
+1, я собственно к этому же :) |
||
14 дек 12, 16:45 [13633344] Ответить | Цитировать Сообщить модератору |
Mind Member Откуда: Лучший город на Земле Сообщений: 2322 |
|
||||
14 дек 12, 22:11 [13635032] Ответить | Цитировать Сообщить модератору |
dbnadm Member Откуда: Сообщений: 101 |
не, ну речь не об этом, я собственно сам никогда больше 16 файлов не добавляю и в данном конкретном случае ядер там было 32. Просто меня поразило что SQL не отловил такой явный косяк и пропустил команду добавить к системной базе данных несколько файлов с одинаковым логическим именем так что это убило сервак. Я считаю это баг который MS неплохо бы было исправить. Я понимаю, вы мне можете сказать ну так к примеру и команду DROP DATABASE на самую главную продакшн базу SQL Server тоже пропустит, ты же сам должен понимать что ты делаешь раз назвался sysadmin. Но удалять базы иногда все таки нужно, а вот добавлять файлы с одинаковыми логическими именами у DBA в принципе не может быть никакого резона плюс такая команда убивает весь сервак. Значит сервер не должен ее пропускать и генерировать ошибку, imho. |
||
15 дек 12, 05:13 [13635709] Ответить | Цитировать Сообщить модератору |
Slava_Nik Member Откуда: из России Сообщений: 891 |
не знаю, как вам рекомендовали, но нам мелкософт рекомендовал, если ядра сгруппированы в NUMA, то файлов должно быть не больше ядер в NUME-е, обычно сейчас это 8 файлов. + скрипту автора, размер инициализации(у вас SIZE = 8MB ) должен быть достаточным, чтобы он не рост, иначе со временем размер файлов будет разным , в итоге сикуль начнет использовать файлы пропорционально их размерам, соответсвенно плюс от кол-ва файлов уменьшится. кстати, по этому косяку, если восстановить базу Master\ или sytemresource, до этого косяка, сикуль поднялся бы? наверно да. а так конечно косяк, что сикуль пропустил такую команду. |
15 дек 12, 11:49 [13635961] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
Я в принципе слышал от микрософта оговорки, что типа нужно делать количество файло по количеству ядер, но обычно делают меньше, а вот почему меньше и какие минусы, если файлов будет много, не говорили... |
||||
15 дек 12, 13:04 [13636130] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
|
||
15 дек 12, 13:05 [13636132] Ответить | Цитировать Сообщить модератору |
Slava_Nik Member Откуда: из России Сообщений: 891 |
[quot alexeyvg]
точно не могу сказать, но смысл этого то , что могут как раз задержки появляться при взаимодействие между Numа-ми уже. |
||||
15 дек 12, 14:00 [13636215] Ответить | Цитировать Сообщить модератору |
step_ks Member Откуда: Сообщений: 936 |
dbnadm, регайте в connect. |
15 дек 12, 20:51 [13637242] Ответить | Цитировать Сообщить модератору |
Idol_111 Member Откуда: Сообщений: 614 |
Пробовать поднимать надо было в минимальной конфигурации, а потом править файлы tempdb. |
||
17 дек 12, 07:22 [13640675] Ответить | Цитировать Сообщить модератору |
dbnadm Member Откуда: Сообщений: 101 |
да, я так тоже подумал первым делом, не вы же один такой умный. Читайте внимательнее, этот подход пробовался, явно же написано выше. |
||||
17 дек 12, 07:59 [13640696] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
И какая версия 2012-го у вас? Релиз или CTP, сервис-паки какие нибуть? |
||
17 дек 12, 08:19 [13640714] Ответить | Цитировать Сообщить модератору |
dbnadm Member Откуда: Сообщений: 101 |
Сорри, но как конкретно ругается на какую команду типа ALTER DATABASE ... FILE я уже не скажу так как машину я уже переустановил и отдал юзерам, а другой тестовой сейчас под рукой увы нет. По поводу версии, это был: Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) |
||
17 дек 12, 10:02 [13640958] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
dbnadm, Ага, понял, спасибо за инфу. |
17 дек 12, 10:33 [13641092] Ответить | Цитировать Сообщить модератору |
Mind Member Откуда: Лучший город на Земле Сообщений: 2322 |
A SQL Server DBA myth a day: (12/30) tempdb should always have one data file per processor core
|
||||||||
17 дек 12, 22:59 [13646129] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
Mind, Да, интересно, спасибо. Тут как раз объяснение, откуда могут взятся тормоза, и рекомендации по количеству файлов. Я-то как раз руководствовался рекомендациями группы SQLCAT (про которую пишут в статье), но действительно это правильно для очень боьших нагрузок и сбалансированной подсистемой IO.
|
||
17 дек 12, 23:51 [13646267] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |