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

Откуда:
Сообщений: 96
Добрый день всем!
Джентльмены, кто обладает опытом или секретными сведениями :), подскажите, пожалуйста: как грамотно запланировать обработку событий по расширению баз данных?
Суть проблемы, которую я затрудняюсь решить такова:
есть сервер MS SQL 2008R2
в рамках данного сервера размещены около сотни баз данных различного объема: от пары мегабайт до ста гигабайт.
под хранение файдов баз данных/логов выделено отдельное умное сетевое хранилище.
Администраторы этого хранилища могут мне предоставить либо увеличение LUNa, на котором лежат базы, либо могут создать еще LUN.
Теоретически, понятно - хотя бы примерно - как поступить в случае, если места на LUNе станет не хватать.
Но как создать грамотный регламент, учитывающий детали, о которые можно споткнуться - у меня по нет отчетливого понимания.

как все-таки приращивать дисковое пространство? Просить администраторов системы хранения увеличивать лун?
Но тогда есть опасность столкнуться с тем что на аварийное восстановление потребуется слишком много времени: надо же учитывать и то то, что сама Windows аварийно свалится и при рестарте потребует запустить checkdisk на проверку логической структуры тома. Если том будет пару терабайт, по-моему, время на проверку тома станет совсем уж не приемлемым.

Вторая возможность: добавлять еще один LUN, затем в файловую группу каждой отдельной базы добавлять еще один файл и размещать его на дополнительном LUNe.
Но тут, как я понимаю, есть опасность того, что я не могу добавлять бесконечное количество томов, "цепляя" их на сервер под определенной буквой. Их же все 26 в латинском алфавите :)

Как быть?
4 апр 13, 12:07    [14134909]     Ответить | Цитировать Сообщить модератору
 Re: Регламент по расширению баз данных  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3637
А что мешает перенести бд на новый lun, а не добавлять новую группу ?
4 апр 13, 12:27    [14135060]     Ответить | Цитировать Сообщить модератору
 Re: Регламент по расширению баз данных  [new]
SvetlanaNikit
Member

Откуда:
Сообщений: 96
ну, теоретически, не вижу препятствий.
но баз-то у меня не одна-две, а почти сотня и их количество будет расти.
Как тогда переносить? только ту базу, которая растет быстрее всех? А как быть тогда с доступностью сервера для пользователей? Ведь перенос базы займет не полсекунды. Кроме того, хотелось бы весь этот процесс максимально формализовать и автоматизировать.
4 апр 13, 12:32    [14135108]     Ответить | Цитировать Сообщить модератору
 Re: Регламент по расширению баз данных  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
SvetlanaNikit
надо же учитывать и то то, что сама Windows аварийно свалится и при рестарте потребует запустить checkdisk на проверку логической структуры тома.
Если у вас свалится винда под нагрузкой, то, скорее всего, чекдиск будет самой минорной из ваших проблем.
SvetlanaNikit
Их же все 26 в латинском алфавите
Зато сколько папок можно сделать...

К сообщению приложен файл. Размер - 32Kb
4 апр 13, 12:34    [14135130]     Ответить | Цитировать Сообщить модератору
 Re: Регламент по расширению баз данных  [new]
SvetlanaNikit
Member

Откуда:
Сообщений: 96
Гавриленко Сергей Алексеевич
SvetlanaNikit
надо же учитывать и то то, что сама Windows аварийно свалится и при рестарте потребует запустить checkdisk на проверку логической структуры тома.
Если у вас свалится винда под нагрузкой, то, скорее всего, чекдиск будет самой минорной из ваших проблем.
это понятно. именно эту проблемы я привела как пример того, что приходится учитывать массу деталей, на которых можно споткнуться.

Гавриленко Сергей Алексеевич
Зато сколько папок можно сделать...

то есть монтировать диски как папки - как в никсах? да, в курсе насчет того, что это давно есть в Windows, но не упомянула потому, что сама ни разу не применяла на продуктивных серверах. Какие могут возникнуть проблемы в этом случае? Какие плюсы - кроме экономии "букв дисков"?
4 апр 13, 12:44    [14135212]     Ответить | Цитировать Сообщить модератору
 Re: Регламент по расширению баз данных  [new]
gang
Member

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

Вводных много, конкретики мало.
1) в рамках данного сервера размещены около сотни баз данных различного объема: от пары мегабайт до ста гигабайт.
Наверное и рос у этих БД разный? Соответственно и новое место требуется далеко не всем из них.

2) сама Windows аварийно свалится и при рестарте потребует запустить checkdisk.
У Вас кластер? Даже если так, эта проверка поддается отключению. Кроме того, если Вы таки хотите неприменно проверять, то какая разница чекать 1 большой кусок или № поменьше?

3) "цепляя" их на сервер под определенной буквой. Их же все 26 в латинском алфавите :)
Таки кластер?

Может это будет полезно...
4 апр 13, 12:45    [14135217]     Ответить | Цитировать Сообщить модератору
 Re: Регламент по расширению баз данных  [new]
SvetlanaNikit
Member

Откуда:
Сообщений: 96
gang
SvetlanaNikit,

Вводных много, конкретики мало.

я понимаю, что не все сумела описать в постановке задачи, поэтому готова пояснять :)

gang
1) в рамках данного сервера размещены около сотни баз данных различного объема: от пары мегабайт до ста гигабайт.
Наверное и рос у этих БД разный? Соответственно и новое место требуется далеко не всем из них.

да, верно.
просто, руководство давно носится с идеей фикс - консолидировать базы с группы мелких серверов под "крышей" одного толстого и сильного сервера. И теперь дошли до реализации "в железе".
Прирост у всех баз незначительный. У кого-то больше, у кого-то меньше, но не драматический.
Тем не менее регламент нужен. Ибо без него опасность бардака - просто катастрофическая.

gang
2) сама Windows аварийно свалится и при рестарте потребует запустить checkdisk.
У Вас кластер? Даже если так, эта проверка поддается отключению.

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

gang
Кроме того, если Вы таки хотите неприменно проверять, то какая разница чекать 1 большой кусок или № поменьше?
я тут начиталась/насмотрелась разнообразных презентаций и - не то чтобы мне было откровение - но соглашаюсь с идеей, что если, скажем, база разделена на оперативную и архивную файловую группы, то время восстановления доступности этой бд для пользователей можно существенно сократить, восстанавливая базу по кускам.
Той же идеей я пользуюсь, рассматривая вариант размещения баз на разных LUNах.
Кстати, насколько я поняла, размещение баз на нескольких лунах благотворно скажется и на повышении производительности - с точки зрения потоков Windows. или я ошибаюсь?

gang
3) "цепляя" их на сервер под определенной буквой. Их же все 26 в латинском алфавите :)
Таки кластер?
да, верно.

gang
Может это будет полезно...
это мне известно и не представляет затруднений.
Сейчас мне важнее выбрать какую-то одну схему обработки расширения баз. Либо - совместить их.
С учетом обозначенного условия6 большое количество баз, которые растут с разной скоростью.
4 апр 13, 13:07    [14135397]     Ответить | Цитировать Сообщить модератору
 Re: Регламент по расширению баз данных  [new]
gang
Member

Откуда:
Сообщений: 1394
Пункт номер ноль - сделать бекап вы уже наверное написали =)

SvetlanaNikit
Прирост у всех баз незначительный. У кого-то больше, у кого-то меньше, но не драматический.
Тем не менее регламент нужен. Ибо без него опасность бардака - просто катастрофическая.

SvetlanaNikit
Сейчас мне важнее выбрать какую-то одну схему обработки расширения баз. Либо - совместить их.
С учетом обозначенного условия6 большое количество баз, которые растут с разной скоростью.


Скорее всего первым делом нужно определить к чему больше стремиться. Вариант 1 "Максимум контроля", Вариант 2 "Минимум бардака".

Вариант 1
При первом варианте желательно установить жесткое соответствие БД*-Раздел диска-LUN*. БД* это либо конкретная база к которой требуется повышенное внимание с точки зрения размера, роста, характера дисковой нагрузки, либо группа баз у которых эти параметры схожи и не требуют пристального контроля. LUN*-Теоретически на SAN-e можно контролировать размещение LUN-ов вплоть до конкретных шпинделей, т.е. добиться жесткого маппинга БД до конкретных физических носителей.
Основная плюшка - минимизация возможности влияния сторонней активности на SAN-е на дисковое хранилище конкретной БД (переподписка весьма занимательная вещь).
В минус сложность администрирования и то, что админы SAN-a не любят заморачиваться такими вещами оставляя физическую организацию хранилища на откуп "умному" контроллеру. Для небольших БД это вполне оправдано, т.к. есть вероятность, что конроллер разнесет файл БД по более чем 1 зеркалу (у Вас же RAID10?).

Вариант 2 - расширять партиции. Плюшки: минимум административных усилий - буквы дисков не меняются, на уровне БД изменений не нужно, все файлы остаются как есть продолжая равномерно расти на расширенном диске по мере необходимости.
Тут только не нужно растить слишком большие куски. До 2008-го кластер не давал делать партиции более 2 Тб. Лучше и сейчас этот размер не превышать. Могут, например, возникнуть трудности если руководство решит, что мало консолидировать надо виртаулизировать, копировать труднее и т.п.

SvetlanaNikit
я тут начиталась/насмотрелась разнообразных презентаций и - не то чтобы мне было откровение - но соглашаюсь с идеей, что если, скажем, база разделена на оперативную и архивную файловую группы, то время восстановления доступности этой бд для пользователей можно существенно сократить, восстанавливая базу по кускам.
Той же идеей я пользуюсь, рассматривая вариант размещения баз на разных LUNах.

Вот это зря. Во-первых в этих презентациях речь скорее всего шла о восстановлении после сбоев (restore DB/File/FileGroup), а не о процессе рекавери при рестарте SQL. Что вы планируете восстанавливать при краше 1 из дисков под кластером?

SvetlanaNikit
Кстати, насколько я поняла, размещение баз на нескольких лунах благотворно скажется и на повышении производительности - с точки зрения потоков Windows. или я ошибаюсь?


Не очень понятно о каких потоках речь. Если Вы имеете в виду, что обращения к диску с разных процессоров пойдут к разным дискам независимо, то теоретически вероятно, но не гарантировано. Во-первых у таких "потоков" будут как минимум 2 общие точки "маршрута" это интерфейсы "сервер"-"SAN" + кеш контроллера, его "мозги", возможно SAN-свич. К тому же если размещением LUN-ов занимается контроллер (а так оно по дефолту), то они вполне могут оказаться на одних и тех же физических шпинделях. Т.е. да, вероятность того что операции будут параллельны есть, но нет гарантии что не будет обратного.
4 апр 13, 14:46    [14135975]     Ответить | Цитировать Сообщить модератору
 Re: Регламент по расширению баз данных  [new]
SvetlanaNikit
Member

Откуда:
Сообщений: 96
понятно, спасибо.

еще вопрос, я дико извиняюсь за оффтоп: как составить список всех пользовательских баз данных для данного экземпляра?
11 апр 13, 16:12    [14168153]     Ответить | Цитировать Сообщить модератору
 Re: Регламент по расширению баз данных  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
select * from sys.databases
11 апр 13, 16:15    [14168178]     Ответить | Цитировать Сообщить модератору
 Re: Регламент по расширению баз данных  [new]
SvetlanaNikit
Member

Откуда:
Сообщений: 96
Спасибо :)
11 апр 13, 16:21    [14168211]     Ответить | Цитировать Сообщить модератору
 Re: Регламент по расширению баз данных  [new]
SvetlanaNikit
Member

Откуда:
Сообщений: 96
Помогите, пожалуйста, разобраться еще в одном вопросе. Проблема, собственно, в планировании все того же кластера MS SQL.

Вопрос по сопоставлению экземпляра SQL Server 2008 с экземпляром MSDTC.
"SQL Server 2008 Failover Clustering"
в этом руководстве, что есть два пути построить сопоставление: установить MSDTC в одну кластерную группу с MS SQL. Или - разнести их в разные кластерные группы.
У меня экземпляр MS SQL и MSDTC находится в своих собственных кластерных группах.

Пытаюсь командой msdtc -tmMappingSet -name testMapping1 -service MSSQLSERVER -clusterResource MSDTC-MSDTC провести это сопоставление.
Но потом проверяю что получилось командой msdtc -tmMappingView * и получаю сообщение: No such Transaction Manager mapping found.
Что я делаю не так?
25 апр 13, 17:20    [14231538]     Ответить | Цитировать Сообщить модератору
 Re: Регламент по расширению баз данных  [new]
SvetlanaNikit
Member

Откуда:
Сообщений: 96
Не, никто не в курсе?
30 апр 13, 09:32    [14247523]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить