Oracle contains не работает
Обновлено: 03.07.2024
У меня возникла проблема с выполнением этого запроса.
После некоторого googling я разобрал эту проблему в индексе, но когда я посмотрел на таблицу и индекс, мне показалось, что это нормально.
Создать script для индекса выглядит следующим образом
Единственное, что мне странно, это то, что когда я смотрю на "Редактировать таблицу в свойствах таблицы в SQL Developer", я вижу, что "Операционный статус индекса" FAILED. Кто-нибудь знает, что это значит? Возможно, права БД?
Также он работает, когда я использую
Спасибо за любой совет
UPDATE
После воссоздания индекса и некоторых игр, я отключил, что могу выполнить запрос выше, но он ничего мне не вернет.
Если я попробую с помощью CONTAINS(gob_a_document, '%') , результат будет 26 строк и не знаю, по какому ключу был выбран запрос (по крайней мере, я не нашел ничего очевидного, я исследую его больше). Проблема может заключаться в том, что мы используем Oracle 10g и сохраняем файлы DOCX, поддерживаемые с версии 11.
sql oracle oracle-sqldeveloper oracle-text
1 ответ
4 Решение APC [2012-03-02 13:01:00]
"Операционный статус индекса FAILED"
- удалить индекс
- заново запустите оператор CREATE INDEX
- если он выдает ошибку, запомните причину и исправьте ее
Если это не очевидно, другой оператор работает, потому что он не пытается использовать ваш индекс CONTEXT. Это делает поиск трудным путем.
"Дело в том, что индекс уже был создан в БД",
"Теперь запрос выполняется, но он не дает мне никаких результатов (0 строк возвращается). (и я уверен, что он должен вернуться как 100 строк)
Итак, похоже, что вы храните документы в двоичном формате. Какие документы? Являются ли они в поддерживаемом формате? Это будет зависеть от того, какую версию Oracle вы используете. Например, Oracle Text 10g поддерживает до Word 2003 (то есть только DOC), тогда как Oracle Text 11g поддерживает Word 2007 (например, DOCX).
До наших дней возможность работы с текстовыми документами в Oracle несколько раз поменяла название (SQL*TextRetrieval -> Text Server -> Oracle ConText -> Oracle Text) и существенно развилась. Начиная с версии 9, она встроена в обычную поставку СУБД Oracle, не требует, как ранее, отдельного лицензирования и автоматически включается в состав типовой БД. При отсутствии же в БД эту возможность можно установить самостоятельно либо при помощи DBCA, либо прогоном сценария dr0inst.sql (версия 9 и предшествующие) или же catctx.sql (с версии 10) в [ORACLE_HOME]/ctx/admin.
Текстовые возможности Oracle находят внутреннее употребление, например в Oracle Ultra Search, Content Management (ранее iFS) или в XML DB.
- CTXSYS.CONTEXT - для выполнения полнотекстового поиска по текстовым документам;
- CTXSYS.CTXCAT - для выполнения упрощенного и ускоренного поиска по «каталогам» (одно-двустрочным текстовым описаниям);
- CTXSYS.CTXRULE - для построения «классификаций» документов при том, что класс описывается набором характерных запросов.
Здесь рассматриваются общие возможности наиболее популярной разновидности индекса CTXSYS.CONTEXT. Этот вид текстового индекса позволяет хранить в БД текстовые документы и выполнять полнотекстовые запросы к документам как внутреннего хранения, так и внешнего (файловая система, интернет).
Простой пример
Подготовка данных
Роли CONNECT и RESOURCE приписаны пользователю CTX для простоты примера, и использовать их в рабочей БД неправильно; роль же CTXAPP употреблена по существу, так как без нее пользоваттель CTX не сможет обращаться к необходимым объектам схемы CTXSYS. Выполним:
Обратите внимание: индекс DOCS_VC2DOC_IDX - не простой, а «прикладной» (domain); точнее - предопределенного типа CTXSYS.CONTEXT, то есть «текстовый». В общем случае создание такого индекса содержит указание ряда специальных параметров (примеры будут далее), но для первого знакомства довольно положиться на умолчательные характеристики.
Примеры запросов
Основой для запросов к документам по индексу типа CTXSYS.CONTEXT является «оператор» CONTAINS. По своему употреблению оператор Oracle SQL практически не отличается от функции. Оператор CONTAINS возвращает меру, иначе степень, соответствия документа текстовому запросу («relevance»).
Несколько поясняющих примеров. Подготовка:
Обратите внимание, что степень соответствия документа запросу не является простой частотой употребления в документе слова. Она зависит также от общего количества запрашиваемых документов и от количества документов, где есть искомые словоформы. Ее вычисление в Oracle основано на формуле Сэлтона. Результат, который дает формула, отображается на диапазон целых чисел между 0 и 100.
Следующие несколько примеров, выполненных самостоятельно, помогут пояснить поведение оператора CONTAINS и получить представление о некоторых дополнительных возможностях контекстного запроса:
Полный перечень и описания реализованых операторов для составления контекстного запроса по документам (название «оператор» здесь неудачно совпадает с именованием «оператором» самой функции CONTAINS) имеется в документации по Oracle.
Возможности иной формулировки
На практике использование обращения к CONTAINS в выражениях для формирования столбцов в предложении SELECT не всегда удобно и не способствует эффективности. Вынужденная в этом отношении мера - использование функции («оператора») SCORE, возвращающей тот же результат, что и CONTAINS, но которую можно повторять в запросе многократно без боязни замедлить вычисление. Однако поскольку операторов CONTAINS в запросе может встречаться несколько, придумана специальная техника числовых «меток», устанавливающих соответствие операторов SCORE и CONTAINS в рамках запроса SQL. Метки указываются как параметр операторов (еще одна вынужденная и не очень элегантная мера) и выбираются произвольно. Примеры этой техники:Текстовый индекс
Практически обработку текстовой информации в Oracle Text обеспечивает текстовый индекс. Содержательно он организует хранение «обращенного списка», который по предъявленному поисковому слову выдает список пар <документ, словоместо>. Для этого он хранит список документов, позиций словоформ в документах и одно или несколько индексируемых слов в каждой позиции.Технически текстовый индекс устроен сложнее обычных B-древовидного или же поразрядного индексов хотя бы тем, что реализован сразу группой объектов и группой структур хранения. В этом легко удостовериться:
- Таблица DR$ DOCS_VC2DOC_IDX$I.
Хранит перечень всех словоформ, попавших в индекс, внутренний номер документа («DOCID») и список позиций словоформ в документе. Вторичные, связанные с ней объекты:- индекс DR$ DOCS_VC2DOC_IDX$X (обычный, типа NORMAL),
- сегменты типа LOBSEGMENT и LOBINDEX для хранения данных поля TOKEN_INFO типа BLOB.
- сегменты типа LOBSEGMENT и LOBINDEX для хранения данных поля DATA типа BLOB.
Пример выдачи из таблицы DR$DOCS_VC2DOC_IDX$I:
Еще одно отличие текстового индекса от обычного в том, что он не правится автоматически при правке документа. Например:
В силу громоздкости текстового индекса сведения о необходимых исправлениях собираются в отдельной таблице, а сама правка выполняется по мере надобности вручную:
(Синхронизировать индекс можно и командой ALTER INDEX, но сейчас фирма Oracle этого не советует).
Стандартный прием - создать задание для плановой корректировки текстового индекса по расписанию.
Планы выполнения запросов
Неуклюжесть (отчасти вынужденная) правки текстового индекса компенсируется высокой скоростью обращения к нему при запросах к СУБД. Однако наблюдать план выполнения запроса приходится в этом случае своеобразно. Обычная команда EXPLAIN PLAN много не даст, но обращение к текстовому («прикладному») индексу она отметит:(Форма выдачи плана соответствует версии 10, по которой готовился материал).
Детали отработки самого текстового (не SQL) запроса наблюдаются через специальную таблицу, а не привычную PLAN_TABLE. Создать ее можно примерно так:
Просмотр плана для конкретного обращения к конкретному индексу делается через специальную процедуру из системного пакета CTX_QUERY:
Пример просмотра сформированного в CTX_EXPLAIN плана обработки текстового запроса:
Все началось с маленькой бумажки, которую принес в брезентовой разносной книге ленивый скороход из коммунотдела.
И. Ильф, Е. Петров. Золотой теленок.
Аннотация
Oracle Text есть штатная возможность СУБД Oracle хранить в общей БД наряду с обычными данными документы и строить запросы, как к этим документам, так и к хранимым в файлах ОС или в интернете. Документы могут быть представлены разными форматами. Рассматриваются начала работы с Oracle Text на основе использования текстового индекса типа CTXSYS.CONTEXT и оператора CONTAINS.
Введение
СУБД Oracle известна в первую очередь как система управления «фактографическими» данными, но с первой половины 90-х годов в ней стали появляться возможности хранить и обрабатывать «сложно устроенные» данные. Одной из первых таких возможностей стала работа в версии 7.3 с частично структурированными данными: текстовыми документами.
До наших дней возможность работы с текстовыми документами в Oracle несколько раз поменяла название (SQL*TextRetrieval -> Text Server -> Oracle ConText -> Oracle Text) и существенно развилась. Начиная с версии 9 она встроена в обычную поставку СУБД Oracle, не требует, как ранее, отдельного лицензирования и автоматически включается в состав типовой БД. При отсутствии же в БД эту возможность можно установить самостоятельно либо при помощи DBCA либо прогоном сценария dr0inst. sql (версия 9 и предшествующие) или же catctx.sql (с версии 10) в [ORACLE_HOME]/ctx/admin .
Текстовые возможности Oracle находят внутреннее употребление, например в Oracle Ultra Search, Content Management (ранее iFS) или в XML DB.
Текстовые возможности СУБД Oracle основаны на использовании специального вида индекса, являющегося одним из встроенных в систему вариантов «предметного» индекса (domain index), используемого для организации работы со сложно устроенными данными. Oracle Text имеет в готовом виде три вида текстового индекса:
- CTXSYS.CONTEXT - для выполнения полнотекстового поиска по текстовым документам;
- CTXSYS.CTXCAT - для выполнения упрощенного и ускоренного поиска по «каталогам» (одно-двустрочным текстовым описаниям);
- CTXSYS.CTXRULE - для построения «классификаций» документов при том, что класс описывается набором характерных запросов.
Здесь рассматриваются общие возможности наиболее популярной разновидности индекса CTXSYS.CONTEXT. Этот вид текстового индекса позволяет хранить в БД текстовые документы и выполнять полнотекстовые запросы к документам как внутреннего хранения, так и внешнего (файловая система, интернет).
Простой пример
Подготовка данных
Для удобства создадим специального пользователя:
> CONNECT / AS SYSDBA
SYS> CREATE USER ctx IDENTIFIED BY ctx DEFAULT TABLESPACE users;
SYS> GRANT connect, resource, ctxapp TO ctx;
SYS> CONNECT ctx/ctx
Роли CONNECT и RESOURCE приписаны пользователю CTX для простоты примера, и использовать их в рабочей БД неправильно; роль же CTXAPP употреблена по существу, так как без нее пользоваттель CTX не сможет обращаться к необходимым объектам схемы CTXSYS. Выполним:
CREATE TABLE docs ( doc_id NUMBER ( 10 ), vc2doc VARCHAR2 ( 4000 ) );
INSERT INTO docs VALUES ( 1, 'Mary had a little lamb' );
INSERT INTO docs VALUES ( 2, 'Twinkle, twinkle little star' );
INSERT INTO docs VALUES ( 3, 'This Lamb is my lamb' );
CREATE INDEX docs_vc2doc_idx ON docs ( vc2doc ) INDEXTYPE IS ctxsys.context ;
Обратите внимание: индекс DOCS_VC2DOC_IDX - не простой, а «прикладной» (domain); точнее - предопределенного типа CTXSYS.CONTEXT, то есть «текстовый». В общем случае создание такого индекса содержит указание ряда специальных параметров (примеры будут далее), но для первого знакомства довольно положиться на умолчательные характеристики.
Примеры запросов
Основной для запросов к документам по индексу типа CTXSYS.CONTEXT является «оператор» CONTAINS. По своему употреблению оператор Oracle SQL практически не отличается от функции. Оператор CONTAINS возвращает меру, иначе степень, соответствия документа текстовому запросу («relevance»).
Несколько поясняющих примеров. Подготовка:
SELECT CONTAINS ( vc2doc, '&1' ) AS score, vc2doc FROM docs.
SAVE simplequestion REPLACE
COLUMN vc2doc FORMAT A60
CTX> @simplequestion ' star '
0 Mary had a little lamb
4 Twinkle, twinkle little star
0 This Lamb is my lamb
CTX> @simplequestion ' little '
4 Mary had a little lamb
4 Twinkle, twinkle little star
0 This Lamb is my lamb
CTX> @simplequestion ' twinkle '
0 Mary had a little lamb
9 Twinkle , twinkle little star
0 This Lamb is my lamb
CTX> @simplequestion ' lamb '
4 Mary had a little lamb
0 Twinkle, twinkle little star
7 This Lamb is my lamb
CTX> @simplequestion ' mary AND lamb '
4 Mary had a little lamb
0 Twinkle, twinkle little star
0 This Lamb is my lamb
CTX> @simplequestion ' mary lamb '
0 Mary had a little lamb
0 Twinkle, twinkle little star
0 This Lamb is my lamb
Следующие несколько примеров, выполненных самостоятельно, помогут пояснить поведение оператора CONTAINS и получить представление о некоторых дополнительных возможностях контекстного запроса:
@simplequestion 'MARY AND LAMB'
@simplequestion 'MaRy AnD lAmB'
@simplequestion 'lamb NOT mary'
@simplequestion 'NEAR ((lamb, mary) ,3)'
@simplequestion 'NEAR ((lamb, mary) ,2)'
@simplequestion 'mary ACCUM lamb'
@simplequestion 'mary ACCUM little'
@simplequestion 'mary ACCUM little lamb'
@simplequestion 'lamb OR little'
Полный перечень и описания реализованых операторов для составления контекстного запроса по документам (название «оператор» здесь неудачно совпадает с именованием «оператором» самой функции CONTAINS) имеется в документации по Oracle.
Возможности иной формулировки
На практике использование обращения к CONTAINS в выражениях для формирования столбцов в предложении SELECT не всегда удобно и не способствует эффективности. Вынужденная в этом отношении мера - использование функции («оператора») SCORE, возвращающей тот же результат, что и CONTAINS, но которую можно повторять в запросе многократно без боязни замедлить вычисление. Однако поскольку операторов CONTAINS в запросе может встречаться несколько, придумана специальная техника числовых «меток», устанавливающих соответствие операторов SCORE и CONTAINS в рамках запроса SQL. Метки указываются как параметр операторов (еще одна вынужденная и не очень элегантная мера) и выбираются произвольно. Примеры этой техники:
CTX> SELECT SCORE ( 1 ), vc2doc
3 WHERE CONTAINS ( vc2doc, 'lamb', 1 ) > 0
4 ORDER BY SCORE ( 1 ) DESC
7 This Lamb is my lamb
4 Mary had a little lamb
CTX> SELECT SCORE ( 1 ), SCORE ( 15 ), vc2doc
4 CONTAINS ( vc2doc, ' lamb ', 1 ) > 0
5 OR CONTAINS ( vc2doc, ' lamb AND mary ', 15 ) > 0
7 SCORE ( 15 ) DESC
SCORE(1) SCORE(15) VC2DOC
4 4 Mary had a little lamb
7 0 This Lamb is my lamb
Текстовый индекс
Практически обработку текстовой информации в Oracle Text обеспечивает текстовый индекс. Содержательно он организует хранение «обращенного списка», который по предъявленному поисковому слову выдает список пар <документ, словоместо>. Для этого он хранит список документов, позиций словоформ в документах и одно или несколько индексируемых слов в каждой позиции.
Технически текстовый индекс устроен сложнее обычных B-древовидного, или же поразрядного индексов хотя бы тем, что реализован сразу группой объектов и группой структур хранения. В этом легко удостовериться:
CTX> COLUMN object_name FORMAT A30
CTX> COLUMN object_type FORMAT A30
CTX> COLUMN segment_name FORMAT A30
CTX> COLUMN segment_type FORMAT A30
CTX> SELECT object_name, object_type FROM user_objects ORDER BY 2, 1;
CTX> SELECT segment_name, segment_type FROM user_segments ORDER BY 2, 1;
В обоих запросах все объекты БД и структуры хранения, кроме DOCS, принадлежат текстовому индексу. Точнее, в результате команды CREATE INDEX docs_vc2doc_idx . появился не только собственно индекс DOCS_VC2DOC_IDX, но и:
- индекс DR$ DOCS_VC2DOC_IDX $X ;
- две обычные таблицы, DR$ DOCS_VC2DOC_IDX $I и DR$ DOCS_VC2DOC_IDX $R, с двумя полями типа BLOB (и соответствующими им сегментами для данных и для LOB-индекса);
- две индексно-организованные таблицы, DR$ DOCS_VC2DOC_IDX $K и DR$ DOCS_VC2DOC_IDX $N .
Например, таблица DR$DOCS_VC2DOC_IDX$I хранит список лексем и поразрядную карту вхождения в документы (поле типа BLOB; здесь не выдается):
CTX> SELECT token_text, token_count FROM dr$docs_vc2doc_idx$i;
Еще одно отличие текстового индекса от обычного в том, что он не правится автоматически при правке документа. Например:
CTX> UPDATE docs SET vc2doc = 'This Land is my land' WHERE doc_id = 3;
CTX> SELECT token_text, token_count FROM dr$docs_vc2doc_idx$i;
В силу громоздкости текстового индекса сведения о необходимых исправлениях собираются в отдельной таблице, а сама правка выполняется по мере надобности вручную:
CTX> SELECT pnd_index_name, pnd_rowid FROM ctx_user_pending ;
DOCS_VC2DOC_IDX AAAMm2AAEAAAABAAAC
CTX> EXECUTE ctx_ddl.sync_index ( 'docs_vc2doc_idx' )
PL/SQL procedure successfully completed.
no rows selected
CTX> SELECT token_text, token_count FROM dr$docs_vc2doc_idx$i;
(Синхронизировать индекс можно и командой ALTER INDEX, но сейчас фирма Oracle этого не советует).
Стандартный прием - создать задание для плановой корректировки текстового индекса по расписанию.
Планы выполнения запросов
Неуклюжесть (отчасти вынужденная) правки текстового индекса компенсируется высокой скоростью обращения к нему при запросах к СУБД. Однако наблюдать план выполнения запроса приходится в этом случае своеобразно. Обычная команда EXPLAIN PLAN много не даст, но обращение к текстовому («прикладному») индексу она отметит:
CTX> EXPLAIN PLAN FOR
2 SELECT * FROM docs
3 WHERE CONTAINS ( vc2doc, 'twinkle AND star' ) > 0;
CTX> SELECT * FROM TABLE ( dbms_xplan.display );
Plan hash value: 3477406887
/ Id / Operation / Name /Rows/Bytes/Cost (%CPU)/Time /
/ 0/ SELECT STATEMENT / / 1/ 2027/ 4 (0)/00:00:01/
/ 1/ TABLE ACCESS BY INDEX ROWID/ DOCS / 1/ 2027/ 4 (0)/00:00:01/
/* 2/ DOMAIN INDEX / DOCS_VC2DOC_IDX / / / 4 (0)/00:00:01/
Predicate Information (identified by operation id):
2 - access("CTXSYS"."CONTAINS"("VC2DOC",'twinkle AND star')>0)
- dynamic sampling used for this statement
(Форма выдачи плана соответствует версии 10, по которой готовился материал).
Детали отработки самого текстового (не SQL) запроса наблюдаются через специальную таблицу, а не привычную PLAN_TABLE. Создать ее можно примерно так:
CREATE GLOBAL TEMPORARY TABLE ctx_explain (
explain_id VARCHAR2 ( 30 )
, operation VARCHAR2 ( 30 )
, options VARCHAR2 ( 30 )
, object_name VARCHAR2 ( 64 )
ON COMMIT PRESERVE ROWS
Просмотр плана для конкретного обращения к конкретному индексу делается через специальную процедуру из системного пакета CTX_QUERY:
, text_query => ' twinkle AND star '
, explain_id => 'twinkle star'
Пример просмотра сформированного в CTX_EXPLAIN плана обработки текстового запроса:
«Мне нравится Oracle, но иногда он заставляет меня лезть на стену», — такими словами начал свой пост разработчик с сайта CodingToFreedom, который, мягко говоря, недоволен этой технологией и называет ее, вероятно в шутку, «чистым злом». Последней каплей стал момент, когда специалисту пришлось вести с программой «битвы эпических масштабов», в результате чего он потратил несколько месяцев на решение ошибок, устранение которых должно занимать не более пяти минут.
Вот почему автор недолюбливает Oracle.
Отсутствие подробностей об ошибке
Каждый, кто когда-либо работал с Oracle SQL, знает, как программа сообщает об ошибках. Уведомления вроде «Invalid SQL statement» или «Missing Right Paranthesis» неинформативны, особенно, если в них нет информации о номерах строк с ошибкой.
В моем представлении Oracle — это парень, который работает на компанию уже десять лет и даже не пытается выполнять свои обязанности как положено, он просто делает какой-то минимум, которого достаточно, чтобы его не уволили.
Уведомления от Oracle настолько же бесполезны, как если вы попросите у кого-то помощи и вас отправят искать решение в Google.
Это не самая сложная ошибка, но чтобы ее устранить нужно определить, почему недостаточно существующих привилегий, а также отладить всю программу. И все это делается для того, чтобы в конечном итоге выяснить, что проблема не в представлениях , а в последовательностях , используемых для увеличения ID столбца, которому нужны привилегии для пользователя.
Oracle не знает, что делает Oracle
Каждый раз, когда пользователь пытается задать программе вопрос, она отвечает как тот парень из магазина, которого вы можете случайно перепутать с продавцом-консультантом — «извините, но я здесь не работаю».
Oracle непоследователен
Посмотрите на этот код. Что вы видите?
![Код_1]()
Кроме того, что это выглядит безобразно и является возможным источником SQL-инъекции , сначала может показаться, что это рабочий код, но это не так. Хотя, если скопировать его в редактор и запустить, он запустится. Почему? Проблема в точке с запятой в конце скрипта. Функция EXECUTE IMMEDIATE везде работает по-разному.
Файлы журнала могут убить ваш скрипт
Представьте, вы работает над кодом, который по всем правилам должен работать, но не работает. В отчаянии вы начинаете добавлять после каждого вызова функции логи, чтобы выяснить, где скрипт перестает работать (потому что, конечно, Oracle просто так вам об этом не скажет). Вы находите все баги и надеетесь, что теперь цикл пройдет без ошибок, но внезапно вы замечаете увеличение переменной счетчика. А затем он останавливается после 459-й итерации из примерно 900.
Как оказалось, Oracle настолько не любит предоставлять пользователям вывод логов, что сам оператор ведения логов может привести к сбою скрипта, когда внутренний буфер вывода логов будет переполнен. Эта ошибка стала последней каплей моего терпения. На отладку у меня ушло несколько часов, а решение этой ошибки было довольно-таки простым:
![Код_2]()
Highload нужны авторы технических текстов. Вы наш человек, если разбираетесь в разработке, знаете языки программирования и умеете просто писать о сложном!
Откликнуться на вакансию можно здесь .Читайте также:
