А Ковязин - Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil

• Название: Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
• Автор: А Ковязин
• Жанр: Программирование

Добро пожаловать в форум...

Тема: "Мир Interbase.." или "FireBird.." Что выбрать

Здравствуйте, Господа!

Начинаю потихоньку знакомиться с InterBase и решил приобрести книжку (поскольку с монитора читать довольно тяжело). Почитав отзывы, понял, что выбирать придется между «Мир InterBase» (Ковязин, Востриков) и «FireBird. Руководство разработчика баз данных) (Х.Борри). К сожалению, денег на обе не хватит.

В связи с этим вопросы:

·Какая из этих книг доступнее для новичка, только начинающего изучать СУБД и проектирование БД

·В какой степени эти книги, так сказать, взаимозаменяемы. Т.е. насколько знания, полученные из книги про InterBase(например) применимы для работы с FireBird и наоборот.

Заранее всем спасибо за ответы.

С уважением, Londinium

---------

Гаджимурадов Рустам

1. Если ты совсем новичек, то бери первую - в ней доступнее.

2. Если ты новичек только в ИБ, то лучше вторую.

3. Вторую книжку желательно иметь под рукой по-любому - независимо от того, есть ли первая.

4. Важно - во второй нет нихрена (кажется) про библиотеки доступа (IBX, FIBPlus).

5. Знания про InterBase, полученные из первой книги, применимы к FireBird практически в полном объеме.

...

---

#define LCK_PR 3

Protected Read

Защищенное Чтение

#defme LCK_SW 4

Shared Write

Совместная запись

#define LCK_PW 5

Protected Write

Защищенная запись

#define LCK_EX 6

Exclusive

Эксклюзивная блокировка

Блокировка типа LCK_none на самом деле представляет собой запрос на снятие существующей блокировки. Блокировка LCK_null - это блокировка существования, которая налагается клиентским соединением. Для этого соединения важно лишь, чтобы заблокированный объект существовал.

Этот тип блокировки используется для того, чтобы гарантировать существование индексов, пока существуют скомпилированные запросы, которые зависят от этих индексов. Взаимодействие уровней блокировки описывается в следующей таблице совместимости блокировок (здесь 1 означает, что данные блокировки совместимы, 0 - несовместимы):

none

null

Shared Read

Protected Read

Shared Write

Protected Write

Exclusive

попе

1

1

1

1

1

1

1

null

1

1

1

1

1

1

1

SR

1

1

1

1

1

1

0

PR

1

1

1

1

0

0

0

SW

1

1

1

0

1

0

0

PW

1

1

1

0

0

0

0

EX

1

1

0

0

0

0

0

Когда соединение желает заблокировать объект, оно подает запрос на блокировку, который определяет блокируемый объект и желаемый уровень блокировки.

Обычно если объект, который какое-то соединение желает заблокировать, уже блокирован другим соединением, то выстраивается очередь доступа, причем соединения, которые желают получить уровень блокировок ниже, чем тот, что уже наложен на объект, продвигаются вперед очереди. То есть если объект был заблокирован с уровнем Protected Read, то следующие соединения, которые запрашивают на этот объект блокировку Protected Read или ниже, передвинутся в начало очереди (точнее, пройдут без очереди), а соединения, которые запрашивают блокировки уровнем выше (например, Shared Write), будут "топтаться" в очереди. Если загрузка базы данных очень велика, такое поведение может привести к тому, что соединения, которые требуют высоких уровней блокировок, могут ждать неопределенно долго, потому что новые читающие соединения (которые запрашивают низкие уровни блокировки) будут постоянно прибывать и "лезть без очереди".

Показания к изменению параметра

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

LOCK HASH SLOTS

Параметр lock hash slots был удален из конфигурационного файла InteiBaseGx. no крайней мере в SuperSener под NT Однако исходный KOI д 1я того, чтобы прочитать и интерпретировать этот параметр, все еще существует.

Параметры в ibconfig

LOCK_HASH_SLOTS 101

Действие

Этот параметр определяет ширину хэш-таблицы, которая используется для поиска блокировок. По умолчанию значение этого параметра 101. Число должно быть простым, чтобы хэш-алгоритм производил хорошее распределение.

Он может быть в диапазоне от 101 до 2048

Объяснение

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

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

Что получается в итоге. Чем длиннее будут цепочки, подвешенные к каждому слоту, тем медленнее будет работать менеджер блокировок. В среднем каждая цепочка должна иметь не более 10 ячеек.

Показания к изменению параметра

Первым признаком для изменения этого параметра должна быть общая низкая производительность системы с большим количеством пользователей и страниц в кеше Запустите инструмент iblockpr из директории %INTERBASE%\Bin для печати блокировок Если средняя длина более 10, увеличьте число этого параметра Для начала умножьте среднюю длину цепочек на число слотов и поделите на 9, а затем возьмите простое целое число, большее полученного значения (но меньшее 2048). Если вы производите подобную настройку на SuperServer, то необходимо также увеличить размер таблицы блокировок.

DEADLOCK TIMEOUT

Параметры в ibconfig

DEADLOCK_TIMEOUT 10

Действие

Этот параметр определяет число секунд, в течение которых менеджер блокировок будет ожидать разрешения обнаруженного конфликта, а по истечении этого срока конфликт будет рассмотрен как потенциальный deadlock (взаимная блокировка)

Объяснение

Применение этого параметра интенсивно тестировали около двух лет назад на системах, которые были такими медленными, что сегодня они не могли бы работать даже в посудомоечной машине. На данное время 10 с являются оптимальным интервалом Рели установить меньший интервал, то проверки на deadlock перегрузят компьютеры, а если более длинный, то пользователи ворвутся в вашу лабораторию и разгромят компьютеры.

Показания к изменению параметра

Deadlock очень редко встречаются в InterBase Обычная ошибка deadlock, ошибка обновления (Update Conflict) не является тем deadlock, который обнаруживается менеджером блокировок. Представляет интерес запрограммировать действительный случай возникновения deadlock (когда А изменяет строк) 1, В изменяет строку 2, затем А пытается изменить строку 2, а В - строку 1, причем все это без подтверждения изменений - без commit), а затем поэкспериментировать с различными интервалами DEADLOCK_TIMEOUT, чтобы увидеть, как изменяется производительность.

LOCK ACQUIRE SPINS

Параметры в ibconfig

LOCK_ACQUIRE_SPINS 0

Действие

Для архитектуры SuperServer этот параметр не производит никакого действия В архитекторе Classic только один клиент одновременно может обращаться к таблице блокировок Доступ к таблице блокировок определяется мьютексом Запрос мьютекса может быть либо условным, когда задержка является ошибкой и запрос должен быть повторен, либо безусловным, когда запрос будет ожидать до тех пор, пока его не обслужат. Параметр LOCK_ACQUIRE_SPINS устанавливает число попыток выполнения условного запроса. По умолчанию - 0 (нуль).

Объяснение

Условный запрос мьютекса повторяется определенное число раз, устанавливаемое параметром LOCK_ACQUIRE_SPINS, а затем превращается в безусловный запрос. Вроде бы это может принести пользу на машинах с несколькими процессорами (SMP). Что весьма сомнительно.

Показания к изменению параметра

Нет.

CONNECTION TIMEOUT

Параметры в ibconfig

CONNECTION_TIMEOUT 180

Действие

Устанавливает время ожидания (тайм-аут) соединения. По умолчанию— 180 с.

Объяснение

Чтобы распознать клиентов, которые некорректно разорвали соединение, включая тех Windows-клиентов, которые выключили свои компьютеры не закрыв приложения, InterBase посылает фиктивный пакет в течение времени ожидания (тай-маута) соединения. Если ответа на запрос нет в течение установленного времени, то InterBase разрывает соединение

Время ожидания также может быть указано в dpb (database parameter block). Соответствующий параметр имеет название isc_dpb_connect_timeout.

Показания к изменению параметра

Чем выше значение этого параметра, тем меньше фиктивных запросов будут загружать сеть. С другой стороны, "мертвые" соединения будут дольше "висеть". Рекомендуется значительно увеличить значение этого параметра, если вы точно уверены, что клиентские приложения не будут некорректно завершать свою работу.