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.
   
  
  

  « Предыдущая страница - Следующая страница »