InterBase: тормозология и глюконавтика
Страница 35. Глюки, о которых утверждается, что они официально устранены в 5.0


Глюки, о которых утверждается, что они официально устранены в 5.0. (Попытался подсчитать - аж в глазах зарябило: порядка 70 штук):

  • Вложенные поздапросы слишком тормозные (ой ли?)
  • Оптимизатор использует лишние индексы. То есть все, которые теоретически можно использовать в данной ситуации. Хотя реально обычно нужно лишь подмножество.
  • Почти идентичные запросы расходуют ЦПУ с разницей в 400 раз (Уууу...).
  • Статистика в ISQL выдаёт отрицательное время (сам видел)
  • Проблемы с производительностью при работе через тормозную сеть (Мы собирались проэкспериментировать с модемом. Между прочим, я подумал - модем не нужен. Просто соединить COM-порты двух машин нуль-модемом и настроить на низкую скорость, скажем, 9600 Кбит. Получим очень точную картину).
  • 3870 Запоротая база (интересно, что они имели в виду?)
  • Вьюшки на основе идентичных запросов оптимизировались по-разному (По-моему - это свидетельство планирования "от фонаря". Такому продукту точно нельзя доверять.)
  • Проблема оптимизатора (не разъясняют, какая) приводила к низкой производительности
  • Backup не восстанавливал признак Enable Forced Writes. (Точно. Поставишь gbak5, начинает восстанавливать.)
  • 5599 Проблема с производительностью вьюшек (ой ли?)
  • Синтаксический анализатор не позволяет update'ить одну таблицу из другой
  • Нужен способ указать расположение каталогов Temp и InterBase. (На самом деле всё можно обойти с помощью ссылок и переменных окружения. Просто это не было документировано.)
  • 6879 gds consistency check (differences record too long (182)) Вроде как я такое видел.
  • Плохая производительность соединений с индексами (Ха-Ха!!!)
  • Gbak обзывает всё "volume 0" (Не видел)
  • Gstat не показывает, была ли база заглушена в однопользовательский режим (Точно)
  • Большие планы не показываются (Да и маленькие порой тоже. И по-моему это глюк клиента, так как проявляется при подключении к серверу как 4, так и 5)
  • Запрос на вьюшке не использует индексы (Не всегда, но хотелось бы верить, что исправили)
  • Обломившийся клиент продолжает потреблять ЦПУ в связи с EVENT'ами (На самом деле далеко не только по этому поводу. interbase исправно дорабатывает все запросы, которые успел принять, какими бы громадными они ни были и что бы с клиентом ни произошло)
  • "GRANT ALL ON table TO user" при 95 таблицах занимает 5 минут. (Ну это мы и так знаем, как лечится)
  • Соединение вьюшек выдаёт ошибку "запоротая база" (Ой как здорово, что мы этого ещё не пробовали! И не будем.)
  • Нет предупреждения, если drop'ается поле, участвующее в сложном индексе с несколькими полями (На самом деле там много каких предупреждений недостаёт)
  • gbak обламывается, если поле числа с масштабом (видимо, имеется в виду decimal или numeric) менятся на простой Integer. (В упор не пойму, причём здесь gbak)
  • Для удалённых grant/revoke требуется лицензия "D". (Речь о текстовом лицензионом файле interbase, в котором прописаны права на различные функции и ключи на их их использование. Лицензия "D" на самом деле официально отвечает за право обновлять метаданные.)
  • Не защищена таблица rdb$user_privileges. (Я проверил и протащился - действительно любой пользователь может навставлять себе любых прав!!!)
  • gbak не восстанавливает базу, если процедуры содержат явные планы (Вот оно!!!)
  • gbak не делает ABORT, если процедуры с планами ссылаются на неактивные индексы (Вот этого я не понял. Ведь сам факт наличия плана прерывает разбэкапный процесс. Или они имели в виду именно создание бэкапа, а не восстановление? Или они понимают что-то другое под ABORT? Или имелись в виду вообще не процедуры?)
  • UDF (функции из внешней DLL) не могут возвращать блобы (не пробовал)
  • Иногда в статистике выдаётся общее время запроса меньше, чем "чистое" время процессора (Это не единственный повод подозревать эту статистику во вранье)
  • isql, извлекая структуру таблицы, забывает имя ссылочного ограничения (На самом деле, если сделать View Metadata, то всё нормально. Если сделать Extract metadata for Table, то покажет только Primary Key. А если сделать Extract Metadata for Database, то извлекается всё, но в виде отдельных alter'ов. Так что реально теряется либо всё, либо ничего. Где это они видели?)
  • Удалённый доступ через последовательные порты ненадёжен (Интересно, почему? По-моему, interbase тут вообще непричём - всё зависит от протокола.)
  • В Unix-версии серверный процесс gds_inet_server запускается даже для тех пользователей, для которых не прописаны лицензии (Видимо, имеется в виду ограничение на количество подключений. Ну и мало ли, что запускается - главное, чтобы не работал. С учётом того, как оптимизирован запуск процессов в Юниксах, это не должно быть проблемой.)
  • Производительность gbak низкая (Подробности не разъясняют. Действительно, gbak5 работает по-быстрее, но я бы не назвал это исправлением глюка)
  • Дублирование проиндексированных полей не проверяется, когда они импортируются из внешнего файла.
  • ISQL иногда вылетает на длинных запросах, содержащих ошибку
  • Сервер падает от некоторых коррелированых подзапросов, на NetWare как следствие, падает вся система. (Этот глюк известен мне ещё с института. Надо написать коррелированный подзапрос на месте поля в части select. В некоторых комбинациях сервер действительно может обвалиться. Хотя в других случаях может и пройти. Правда, выдаст всякую муру.)
  • SYSDBA не может измнять права пользователей, если перебэкапить базу из версии 3 в 4 (Ха-Ха)
  • gpre портит имена именованных транзакций (К сожалению, мы никогда не писали приложения interbase на Це. Утилита именно для этого и очень интересная.)
  • Нет сообщения от isql при попытке соединения с некорректным именем и паролем. (Видимо, имеется, в виду isql, который с командной строки)
  • Иногда руками удаляются rdb$triggers.
  • Иногда подсчёт записей distinct неверен. (Ха-Ха-Ха! InterBase считать не умеет!)
  • Distinct заставляет игнорировать order by. (Вот не замечал! Что действительно есть, так это то, что distinct без order by всё равно приводит к сортировке по всем полям подряд, начиная с первого. По всей видимости, interbase таким образом выявляет дубликаты. Но вот чтобы забыть потом это всё отсортирить по order by?... Эту ошибку помянули потом ещё раз. Даже в этом у них глюк.)
  • Привилегия References на таблицы не задокументирована (Совершенно точно. Существует в 4 версии отдельное право создавать ссылочные ограничения)
  • Не проходят гранты на группу. (Сделал Extract metadata для isc4.gdb, где хранятся пользователи и оказалось, что там в полях хранятся имена не только пользователей, но и групп, их соответствие пользователям системы (в стиле Unix: UID, GID), а так же информация о компьютерах, которая, видимо, призвана ограничить доступ с конкретных машин. Вот только как этим всем воспользоваться? То что grant'ы можно вставлять руками в метаданные, факт известный)
  • isql не анализирует количество кэш-буферов (Причём оно здесь?)
  • Ошибки с кодировками в базах перебэкапленых из 3.3 в 4.0
  • gds_lock_print -i обламывается (Имеется в виду юниксовая версия утилиты, которая печатает список текущих блокировок)
  • Из-за предварительной выборки при удалённом доступе теряются точные коды ошибок (не замечал)
  • Drop procedure делает Access Violation (Да чего с ними только не бывает)
  • Классы доступа не переносятся из 3 в 4 (Имеется в виду одно из полей в дебрях системных метаданных)
  • Исключение в триггере не предотвращает удаление записи (Класс!)
  • Коррелированный подзапрос не выдаёт правильное количество полей (На самом деле из подзапроса вообще не должны вылезать поля - это недокументированный приём, который ко всему ещё и сервер уронить может)
  • Некоторые утилиты gds_xxxx закрывают за собой только 20 файлов (На самом деле, в Unix часто так поступают. Всё равно система всё закроет. Могли бы и не причислять это к глюкам.)
  • gbak обламывается, если процедура вставляет необновляемую вьюшку (Что-то такое нам попадалось. Вообще из процедур лучше обновлять только хранимые таблицы.)
  • gpre чего-то неправильно обрабатывает в COBOL'овских программах
  • isql -x неправильно выдаёт описания доменов
  • Error: Unsuccessful metadata update: depth exceeded (recursive definition). Никогда не видел.
  • ON UPDATE SET DEFAULT feature (RI/CASCADE) не работает. (Так оказывается, другие режимы работают!!!)
  • Сообщения с длинной сообщения, но без самого сообщения, обламывают сервер (Интересно, про что это?)
  • Внешняя функция, возвращающая cstring длинной более 32752 делает GPF в interbaseserver.exe (У нас все строковые функции возвращают cstring(254), который воспринимается так же, как varchar. С учётом того, что передать на вход функции более 512 байт вообще не получалось, непонятно, откуда могут взяться такие длиннющие строки на выходе. Только в результате глюка внутри самой функции.)
  • Глюк в оптимизаторе при том же запросе с другим порядком перечисления полей (Опять эта тема ...)
  • Файл базы во владении пользователя root - не лучшее решение. (Вообще-то interbase под Unix ставится весь под пользователя root. Что и есть крайне нехорошо. Приходится потом руками восстанавливать безопасность системы.)
  • Solaris затыкается при запуске gbak. (Если это так, то это позорная проблема Соляриса. Unix не имеет права затыкаться от пользовательских утилит. По крайней мере, я в Linux и FreeBSD про такое не слышал. Если, конечно, ядра не отладочные.)
  • gper может сделать segmentation falult при обработке динамических запросов в программе на COBOL'е. (Это точно не про нас.)
  • Внешние таблицы - дыра в системе безопасности
  • Внешние таблицы некорректно бэкапятся и восстанавливаются (По-моему внешними таблицами вообще можно пользоваться только во временных целях для того, чтобы закачать в базу кучу данных)
  • Система Solaris может повиснуть при создании ссылочных ограничений (Позор джунглям!!!)
  • Нет опций для -user и -password в gsec (Ниччё не понимаю. Есть там такие параметры. И нормально работают.)
  • В программах на Це и Коболе получаются разные коды ошибок (Не всё ли равно?)
  • isql неправильно выдаёт метаданные по международному домену (Кодировку имеют в виду что ли?)
  • Differences record is too long (182) Подробности не расшифровывают
  • Временные имена полей (select выражение as имя, ...) не работают с union. (Не замечал)
  • Имя кодировки включается в значение по умолчанию для поля (А почему бы и нет, если поле строкове? В чём тут глюк?)
  • Нарушения целостности хранимых процедур могут обрушить сервер (Эка невидаль! Только вот действительно ли устаранено?)
  • Не задокументирована возможность обновлять вьюшки через триггера (Ну мало ли?)
  • gbak -o обламывается на базе со внешними функциями (Сколько помню, он всегда обламывался при работе со внешними функциями в любом режиме)
  • get_blob_segemnt, put_segemnt, и BLB_lseek вешают многопоточный сервер Мораль: не пользуйтесь многопоточными, если есть возможность.
  • select, включающий order by вешает сервер (Хоть бы пример привели, паразиты)
  • Ошибка взаимоблокировки (deadlock) в 4.2.1
  • Если клиентской функции isc_dsql_fetch() (то есть чтение очередной записи из запроса) передать в качестве параметра XSQLDA вместо ссылки NULL, то удалённый сервер повиснет (Я тащусь!)
  • "4.5 Sync err, localhost err and server dies" По-моему, это непереводимая игра слов с использованием местных идиоматических выражений.
  • isql -x не извлекает данные из баз до 4.5 (C учётом предыдущих ошибок, что он вообще правильно извлекает? И что такое 4.5: interbase или ODS?)
  • gbak спотыкается на взаимоблокировке при восстановлении
  • gpre -x не работает (Ну и фиг с ним)
  • Проблема с дропаньем таблицы в ISQL после дропанья хранимых процедур
  • "Depth exceeded error from schema file in ISQL1_05 TCS test" Ниччё не понимаю!
  • Сервер использует "interbase", что не разрешено в качестве имени пользователя на HP10 (По-моему, это глюк HP10)
  • Приложения на Коболе возвращают SQLCode 0, когда требуется -100
  • Неоднозначное обновление по позиции курсора, если есть несколько курсоров с таким именем (Это из области работы с gpre)
  • В анализаторе динамического SQL: можно обозвать курсор зарезервированным словом и этим словом больше нельзя будет пользоваться
  • Создание ограничения приводит к созданию индекса, что делает невозможным drop table/field. (Не замечал. Разве что foreign key, то тут всё понятно, оно и не должно дропаться.)
  • isql не показывает ограничение not null (По-моему - враньё)
  • Сервер падает от select, у которого в order by длинное поле varchar
  • Операции не всегда корректно наследуют привилегии процедур (Мы этим не пользуемся, хотя механизм интересный.)
  • gstat -x не показывает всех своих опций
  • "Cannot read error for isc_guard1.machine if start as interbase user"
  • Consistency check error, если грант делается перед грантом юниксовой группе (Вот кто бы рассказал, как заставить interbase работать с юниксовыми групами. Кроме как пихать их руками в ISC4.GDB)
  • Сообщения об ошибке при distinct в подзапросах (По-моему ооочень гремучая комбинация, лучше не пробовать. Если не обвалит сервер, то заткнёт производительность - точно.)
  • Ошибка при использовании select distinct на таблице с индексом по соответствующему полю в хранимой процедуре (по четвергам чётного месяца за 11 минут до полуночи при полной луне и юго-западном ветре ...)
  • Сервер не возвращает память операционной системе (Нечего было давать такому серверу)
  • Таймаут при глушении базы в однопользовательский режим с помощью gfix не работает (Зато там есть такой ключ: -immediate)
  • "ALTER TABLE ... DROP CONSTRAINT command drops interbaseserver" Клинический случай
  • Отсутствие drop generator не разъяснено в документации
  • gbak напрямую в стример не работает
  • alter table ... drop поле не проходит, когда должно
  • select с одиночным count() обваливает сервер (Не видел)
  • gpre забывает добавить END-IF в программе на Коболе
  • Индексы использовали character set ID вместо чего-то там, в результате чего в некоторых случаях вылезала ошибка not found.
     
 
« Предыдущая статья