Цитата Busla:
как вы связываете зрение и слух? - Если уши отрезать - папаха на глаза упадёт. Если серьёзно, то какая связь между разрядностью системы и объёмом файла?
Я бы советовал увеличивать объём файлов меньшими порциями - за раз откушать 2Гб - достаточно ресурсоёмкая операция даже для современного сервера. »
|
Если серьезно - учите матчасть.
Могу привести два аргумента, теоретический и практический:
1) В 32х битной системе процессу больше двух гигабайт памяти не выделяется.
Потоки делят память внутри процесса.
Идеальный случай:
- у вас много памяти, по крайней мере достаточно для безпроблемного кеширования всего и вся, или размер данных не велик и полностью влезает в память.
- один файл данных обслуживает один процесс кэширования операций чтения/записи.
- Файлов много, процессов кеширования тоже.
Так вот, дорогой друг, при размере файла данных более 2 гигабайт, даже при наличии свободной памяти, один процесc не сможет обслужить файл данных, дабы тот целиком влез в кэш.
А при не равном соотношении количестве процессов - файлов это уже конкуренция за ресурсы.
Естественно на это имеет смысл обращать внимание лишь в высоконагруженных системах.
2) Есть такая фирма SAP AG со своим продуктом ERP SAR R/3. Он работает на многих RDBMS (в том числе и MS SQL) как 32х,
так и 64х битных.
Продукт часто старше IT-шников которые его обслуживают. Ну да ладно, оставим лирику.
Для 32 битных систем, файлы данных в RDBMS выделяются размерами по 2 ГБ.
Естественно все зависит от размера базы данных. Все вышеперчисленные замечания верны для больших DB.
SAP R/3 4.7 при развертывании с нуля создает базу около 60 ГБ.
SAP NetWeaver - соответственно больше.
Даже если резать кусками по 2 ГБ - это уже 120 файлов "пустой" базы.
Цитата kim-aa:
|
Т.к. вы используете 32х битную систему, я бы рекомендовал выделять файлы данных под данные и логи размером в 2GB. »
|
Да, сказано не удачно, привычка к большим базам, - признаю.
Вот как это звучало бы верно:
Для 32х битных систем размер файла данных не должен превышать предела выделения памяти процесу - 2 ГБ.
Возможно использование файлов меньшего размера, однако нужно осознавать что при росте колличества мелких файлов кеширование на уровне RDBMS станет все менее эффективным, т. к. узкое место переместится в область файловых и I/O операций.
Так же необходимо соизмерять размер наибольшей логической структуры данных - таблицы, с наименьшим размером физической структуры данных - файлом, где сия таблица будет пребывать.
При наличии свободного места на HDD, рекомендуется заранее создавать файлы данных ( файл устройств - в терминах MS SQL 6.x).
Этим вы как резервируете место на будущее, так и обеспечиваете нефрагментированность файла данных на уровене файловой системы. В MS SQL 6.x можно было создать файлы устройств, но не выделять их базам - т.е. зарезервировать место.
Как обстоит дело сейчас - не ведаю.
--------------------------------------------------------------------------
Цитата Busla:
|
это плохая идея. Т.к. некоторая нетипичная операция может потребовать больше пространства, чем задумано непредусмотрительным админом. В итоге БД упадёт - лог транзакции не сможет записаться до конца, в итоге будет не откатить операцию, но и завершить операцию не получится из-за "нехватики" места. »
|
Это стандартная идея.
Опять же два аргумента:
1) В умных книжках рекомендуют делать все руками - надежнее знаете ли.
Да, при неизвестной нагрузке и абсолютно новой базе, лучше включить все на автомат, т. к. разработчику виднее.
Но если администратор BD, после квартала эксплуатации не может сформировать график роста данных и зафиксировать
максимальные нагрузки, то - "Вон из профессии!" (с) art lebedev
2) Если в системе появились "нетипичные операции", то нужно убивать либо программистов (обычно они первые гадят), либо пользователя, либо администратора.
---------------------------------------------------------------------------
Цитата Busla:
|
Это в MySQL можно дамп БД сделать, в MS SQLServer такого понятия нет. »
|
Да вы что? А команда DUMP DATABASE ?
