|
|
Почему растет размер BI файла?
Когда создается новый .bi файл, то в нём автоматически размещается четыре кластера. До версии Progress 9.x по умолчанию размер кластера был равен 16Кб, после – 512Кб. BI кластеры управляются как двусвязный список, т.е. он содержит точки forward и backward. Когда транзакция стартует, информация об этом сохраняется в первом кластере. Когда это кластер будет заполнен, произойдет переход к следующему кластеру. В итоге, когда все четыре кластера заполнятся не завершенными транзакциями, необходимо принять решение о расширении BI файла или о перераспределении для повторного использования существующего пространства, если это возможно. Если первый кластер не будет к этому времени содержать активных транзакций, то он будет помечен как «последний» кластер и повторно использован, таким образом, в BI файле второй кластер становится «первым», пока в следующий раз не понадобится принимать решение о «расширении или перераспределении» пространства.
Но если кластер всё еще содержит незавершенные транзакции, то он не может повторно использоваться. В этом случае, BI файл вынужден «расти», добавляя новый кластер, в нашем случае это будет кластер с номером 5. Как только и он будет заполнен, то процесс принятия решения о перераспределении пространства повторится снова. И если опять первый кластер будет содержать хотя бы одну не завершенную транзакцию, то расширение BI файла, путем добавления нового кластера, продолжится. В конце концов, транзакция в первом кластере когда-нибудь завершится, и кластер станет доступным для использования, и добавление новых кластеров прекратится.
Почему же не завершенные транзакции так долго могут находиться в первом кластере?
Самый простой пример, и к сожалению самый распространенный, это когда пользователь покидает своё рабочее место на долго, в то время когда приложение вынужденно ожидать ввода им каких-либо данных, для того чтобы завершить транзакцию. А поскольку этот кластер не может быть пропущен (skipped over), это и есть управление двусвязным списком, то BI файл будет продолжать расти, добавляя новые кластера при необходимости.
Иногда, не возможно избежать расширения BI файла, и нет достаточного количества времени, чтобы дождаться завершения транзакции, чтобы сделать кластер доступным прежде, чем он станет необходим другим транзакциям.
Так же, иногда, при изменении схемы больших баз данных (>1Гб) BI файл может вырасти до экстремальных размеров. Чтобы это исправить, начиная с версии Progress 8.2A, был введен механизм “Fast Schema Change”, который позволяет изменять схему намного быстрее, и при этом не использовать большое количество пространства BI файла. В 9-ой версии Progress, был введен механизм “Schema Versioning”, который при изменении схемы использует пространство BI файла только когда добавляется или удаляется индекс из таблицы базы данных, когда же добавляются или удаляются поля, BI файл не используется.
Кстати, до 9-ой версии, Progress ограничивал рост размера BI файла в пределах 2Гб, не зависимо от того, как физически размещены BI экстенты. Другими словами, общий размер всех BI экстентов не должен был превышать 2Гб. В версии Progress 9 обработка BI экстентов выполняется по другому. Теперь общий размер BI экстентов мог превысить 2Гб. А начиная с версии 9.1С, когда ввели Large Files Support, каждый экстент мог превысить 2Гб, конечно же если Large Files был активирован и операционная система поддерживала работу с большими файлами.
Чрезмерный рост BI файла, как правило, происходит, когда транзакция стартует, остается активной и открытой в течении длительного периода времени. Это потому, что BI файл организован из секций, называемых кластерами. Каждый кластер заполняется BI заметками, и BI файл расширяется, добавляя новый кластеры, чтобы обеспечить хранение этих заметок. Для того чтобы минимизировать возможность роста BI файла, кластеры могут повторно использоваться, но только тогда, когда все транзакции, которым принадлежат BI заметки, применены к базе данных и закрыты.
Так как BI заметки записываются в BI файл последовательно, то и кластеры могут быть повторно использованы только в последовательном порядке. Это означает, что достаточно одной открытой активной транзакции в Progress, чтобы добавление новых кластеров продолжалось в том время, когда другие пользователи открывают и закрывают транзакции.
Есть две основные причины возникновения долгоиграющих транзакций, это использование ESQL или ODBC. Так же, любое приложение должно придерживаться следующего утверждения: “Транзакция, это действие, которое должно завершиться полностью, или ни когда, т.е. все действия должны быть отменены”. Отсюда:
- Когда вы импортируете данные из файла, лучше это делать так чтобы на каждую запись формировалась одна транзакция, вместо того чтобы создавать одну большую транзакцию.
- Если область действия транзакции большая, то её лучше разделить на более мелкие транзакции с меньшими областями действия.
- Размер транзакции может зависеть от размера основной базы данных. Чем больше становится база данных, тем больше могут быть транзакции.
- Иногда, транзакция, запущенная во время пользовательского сеанса, может не закончится до завершения сеанса, и может расти в течении всего дня.
- Всегда анализируйте свой код на предмет возможного формирования долгоиграющей транзакции, и в этом случае, старайтесь по возможности пересмотреть транзакционную логику такого приложения.
В случае, когда вы заметили чрезмерный рост BI файла, то с помощью promon вы можете посмотреть список пользователей у которых имеются активные транзакции. Для этого после входа в promon, вам необходимо перейти к экрану Active Transaction, т.е. R&D -> 1 (Status Display) -> 4 (Processes/client…) -> 3 (Active Transaction). Транзакции, время которых будет превышать более 10 минут, можно считать подозрительными. Поэтому, стоит связаться с пользователями, которым принадлежат такие транзакции и выяснить, что же они делают. Чаще всего, именно такой подход позволяет определить причину, почему транзакция выполняется так много времени, а её прерывание является лучшим решением для прекращения роста BI файла.
Начиная с версии Progress 8.3, введен параметр запуска базы данных называемый Recovery log Threshold (-bihold), с помощью которого можно ограничить максимальный размер BI файла, выше которого он не может вырасти. Как только это пороговое значение будет достигнуто, база данных выполнит аварийную остановку. Такое поведение базы данных, гарантирует, что свободного дискового пространства будет достаточно для восстановления базы данных. В противном случае, есть вероятность, что размер BI файла станет настолько большим, что заполнит всё имеющееся дисковое пространство, и тогда восстановить базу будет достаточно сложно или вообще не возможно.
(Башкатов В.Г. 2009)
|
|
|
|
Главная
