Планирование ёмкости базы данных Цель: рассмотреть управление дисковым пространством СУБД. План: 1) Размер БД. 2) Производительности БД. 3) Объём внешней памяти. Одна из важных функций системного администратора и администратора базы данных это выделение, управление и мониторинг необходимого пространства для SQL Server и базы данных. Оценка требуемого базе данных пространства может помочь п ланировать ваше пространства и определить требования аппаратной части. Когда планируется база данных, то настраивается логическая структура. Под этой структурой несколько физических файлов и объектов которые отнимаю т дисковое пространство. Они включают журнал транзакций, таблицы и индексы которые составляют файлы данных. Когда создаётся база данных, SQL Server создаёт копию базы данных model, включающую системные таблицы, которые содержат информацию о фа йлах, объектах, правах доступа и ограничениях. Эти таблицы увеличиваются в размере когда вы создаёте объекты в базе данных. Каждый объект, который вы создаёте генерирует новую строку, которая вставляется в одну или несколько системных таблиц. Рассматриваются следующие факторы, когда рассчитывается размер пр остранства базы данных, которую она будет занимать: 1) размер базы данных model и системных таблиц, включая проектируемое приращение; 2) количество данных в таблицы, включая планируемое приращение; 3) количество и размер индексов, особенно размер ключевого поля, количество строк и фактор заполнения свойств; 4) размер файла журнала транзакций, на который влияет частота модификаций, размер каждой транзакции и как часто вы резервируете или очищаете журнал; 5) размер системных таблиц, таких как количество пользователей, объекто в и подобного. В начале выделяется под журнал транзакций от 10 до 25 процентов размера вашей базы данных для OLTP окружения. Вы можете выделить меньший процент для баз данных используемых напрямую для запросов. После того, как определяется количество пространства, выделенное для базы данных model, рассчитывается количество данных в вашей таблице, включая проектируемое приращение. Это может быть рассчитано с помощью определения общего количества строк, размера строк, количества строк в странице и общее количество страниц, необходимых для каждой таблицы в базе данных. Можно оценить количество страниц необходимых для таблиц и дисков ое пространство, которое будет занимать таблица, если вы знаете количество символов для каждой строки и приблизительное количество строк, которые будут храниться в таблице. Используем следующий метод: посчитать количество байтов в строке по общему количеству байтов в каждой колонке. Если одна или более колонок объявлена с изменчивым размером, вы можете прибавить среднее значение колонки для всех строк. Определим количество строк, содержащихся в каждой странице данных. Чтобы сделать это, разделим 8060 на количество байтов в строке. Округлим результат в меньшую сторону до ближайшего целого числа; Разделим среднее количество строк в таблице на количество строк хранящихся в каждой странице данных. Результат равен количеству страниц, котор ые необходимы для хранения вашей таблицы. Для обеспечения наибольшей производительности своей базы данных, используем следующим способом: использовать RAID для улучшения производительности и обеспечения терпимости к ошибкам. использовать аппаратный RAID для более быстрого доступа к данных, и увеличения защищённости данных, и использовать подходящий уровень RAID для достижения прироста производительности, который вы хотите обеспечить и необходимый уро вень терпимости к ошибкам. Если возможно, используйте RAID с параллельной записью прежде чем использовать файловые группы; Помещайте файлы данных и журнал транзакций на отдельные физические диски с отдельными контроллерами ввода вывода. Это позволяет журналу транзакций при операциях записи не соперничать с конкурирующими INSERT, UPDATE или Delete операциями в базе данных; Используйте файловые группы определённые пользователем, д ля помещения объектов базы данных на отдельные диски для облегчения стратегии резервного копирования в очень больших базах данных. Это позволяет вам устано вить индивидуальную стратегию резервного копирования основанную на час тотерезервирования данных. Если вы имеете группу файлов, которая изменяется очень часто, вы можете резервировать эту таблицу или объект чаще. Определение требований к операционной обстановке. Для выполнения этого этапа необходимо знать (хотя бы ориентировочно) объём работы издательства (т.е. количество книг, авторов и заказчиков), а также иметь представление о характере и интенсивности запросов. Объём внешней памяти, необходимый для функционирования системы, складывается из двух составляющих: память, занимаемая модулями СУБД (ядро, утилиты, вспомогательные программы), и память, отводимая под данные ( ). Наиболее существенным обычно является . Объём памяти , требуемый для хранения данных, можно приблизительно оценить по формуле где li – длина записи в i-й таблице (в байтах), Ni – примерное (максимально возможное) количество записей в i-й таблице, Na – количество записей в архиве i-й таблицы. Коэффициент 2 перед суммой нужен для того, чтобы выделить память для хранения индексов, промежуточных данных, для выполнения объёмных операций (например, сортировки) и т.п. Посчитаем приблизительно, какой объём внешней памяти потребуется для хранения данных. Примем ориентировочно, что: 1) одновременно осуществляется около пятидесяти проектов, работа над проектом продолжается в среднем два месяца (по 0,3К); 2) в компании работает 100 сотрудников (по 0,2К на каждого сотрудника); 3) издательство сотрудничает с тридцатью авторами (по 0,2К); 4) в день обслуживается порядка двадцати заявок (по 0,1К); 5) устаревшие данные переводятся в архив. Тогда объём памяти для хранения данных за первый год примерно составит: Mc = 2(100*0,2+6(50*0,3)+30*0,2+250(20*0,1)) = 1232 К или 1,2 М, где 250 – количество рабочих дней в году, а 12 мес./2 мес. = 6. Объём памяти будет увеличиваться ежегодно на столько же при сохранении объёма работы. Объём памяти, занимаемый программными модулями пользователя, обычно невелик по сравнению с объёмом самих данных, поэтому может не учитываться. Требуемый объём оперативной памяти определяется на основании анализа интенсивности запросов и объёма результирующих данных. Рекомендуемая литература: 16, 18.
