Ora 00907 отсутствует правая скобка

I have been looking at this code for the past two days now and I can not seem to get it to work. It keeps giving me ORA-00907: missing right parenthesis . I know that this is a topic that comes up a lot but for some reason none of the examples I have seen has helped me. Can someone please tell me why I got this error and how do I fix it. I am pretty sure that it has nothing to do with my parenthesis, maybe its my CONSTRAINTS

Here are the results I get when I run the code:

Создан 04 июл. 14 2014-07-04 21:12:14 user3806509

There is a comma missing at the end of the previous line. – wildplasser 05 июл. 14 2014-07-05 14:12:26

4 ответа

Albeit from the useless _T and incorrectly spelled histories. If you are using SQL*Plus , it does not accept create table statements with empty new lines between create table ( and column definitions.

Создан 04 июл. 14 2014-07-04 21:19:06 Michael-O

Firstly, in histories_T, you are referencing table T_customer (should be T_customers) and secondly, you are missing the FOREIGN KEY clause that REFERENCES orders; which is not being created (or dropped) with the code you provided.

There may be additional errors as well, and I admit Oracle has never been very good at describing the cause of errors — «Mutating Tables» is a case in point.

Let me know if there additional problems you are missing.

Создан 04 июл. 14 2014-07-04 21:35:02 ron tornambe

I am not sure I understand what you are saying here, » you are missing the FOREIGN KEY clause that REFERENCES orders; which is not being created (or dropped) with the code you provided. CREATE TABLE orders ( order_id VARCHAR2 (10) PRIMARY KEY, order_date DATE DEFAULT, m_p_unique_id VARCHAR2 (10), CONSTRAINT FK_m_p_unique_id_orders FOREIGN KEY (m_p_unique_id) REFERENCES library (m_p_unique_id) ON DELETE CASCADE); – user3806509 05 июл. 14 2014-07-05 00:48:50

I would recommend separating out all of the foreign-key constraints from your CREATE TABLE statements. Create all the tables first without FK constraints, and then create all the FK constraints once you have created the tables.

You can add an FK constraint to a table using SQL like the following:

In particular, your formats and library tables both have foreign-key constraints on one another. The two CREATE TABLE statements to create these two tables can never run successfully, as each will only work when the other table has already been created.

Separating out the constraint creation allows you to create tables with FK constraints on one another. Also, if you have an error with a constraint, only that constraint fails to be created. At present, because you have errors in the constraints in your CREATE TABLE statements, then entire table creation fails and you get various knock-on errors because FK constraints may depend on these tables that failed to create.

Создан 04 июл. 14 2014-07-04 22:04:14 Luke Woodward

Here is a full list of the errors:

Foreign key constraints require us to nominated the referencing column(s) on the child table as well as the referenced column(s) on the parent table. So the foreign key declarations should look like this: ‘CONSTRAINT fk_order_id_orders FOREIGN KEY (order_id) REFERENCES orders (order_id) ON DELETE CASCADE`
The referenced table (and the referenced primary key or unique constraint) must already exist before we can create a foreign key against them. So you cannot create a foreign key for HISTORYS_T before you have created the referenced ORDERS table.
The order of components is not arbitrary. We have to declare all the columns before we declare the table level constraints. This affects both ORDERS and HISTORYS_T.
You have misspelled the names of the referenced tables in some of the foreign key clauses (LIBRARY_T and FORMAT_T).
You need to provide an expression in the DEFAULT clause. For DATE columns that is usually the current date, DATE DEFAULT sysdate.

These are all syntax errors. You would have wasted considerably less than two days on this if you had looked properly at Oracle’s documentation. Find it here.

As well as errors, your scripts contain mistakes.

You have not named most of your constraints. Oracle will give them a default name but it will be a horrible one, and makes the data dictionary harder to understand. We should always explicitly name every constraint.
It is useful to create the constraints with separate statements. Creating tables then primary keys then foreign keys will avoid the problems with dependency ordering identified above.
You are trying to create cyclic foreign keys between LIBRARY_T and FORMATS. You can do this by creating the constraints in separate statement but don’t: you will have problems when inserting rows and even worse problems with deletions. You should reconsider your data model and find a way to model the relationship between the two tables so that one is the parent and the other the child. Or perhaps you need a different kind of relationship, such as an intersection table.
The naming convention of LIBRARY_T is ugly. Try to find a more expressive name which doesn’t require a needless suffix to avoid a keyword clash.
T_CUSTOMERS is even uglier, being both inconsistent with your other tables and completely unnecessary, as customers is not a keyword.

Создан 05 июл. 14 2014-07-05 14:08:48 APC

Некоторые ошибки и их устранение

SP2-1503/SP2-0152

Windows Server 2003 R2 с установленным на нём Oracle Client 10.2.0.4.
При запуске sqlplus от имени пользователя с администраторскими полномочиями коннект осуществляется без проблем. Но при попытке подключиться к базе от имени пользователя без администраторских полномочий появляется ошибка:

Вызвано это невозможностью создать global object пользователем без администраторских полномочий. Я решил проблему так:

Результат — ошибок нет, пользователь счастлив и может работать.

ORA-28759: сбой при открытии файла

При выполнении обращения из БД (под Windows) к серверу с поддержкой SSL (по HTTPS) появилась ошибка:

Суть проблемы в том, что Oracle Wallet Manager (OWM) при редактировании wallets меняет разрешения на доступ к файлу. В результате файл становится доступным только пользователю, от которого был запущен OWM.

Решение:
Измените разрешения на доступ к файлу так, чтобы пользователь, от которого работает Oracle DB, имел доступ хотя бы на чтение.

ORA-12154: TNS:could not resolve the connect identifier specified

PL/SQL Developer и Windows x64.

sqlplus

При попытке подключиться с помощью sqlplus, используя Easy Connect, тоже можно получить ошибку:

Для решения убедитесь, что » $ORACLE_HOME/network/admin/sqlnet.ora » или вообще не содержит параметра » NAMES.DIRECTORY_PATH «, или данный параметр имеет одним из значений (или единственным значением) » EZCONNECT «:

Ошибка компиляции при установке Oracle Client

Первоначально пробуем выполнить:

Для Ubuntu 14.04 вероятно придётся пересоздать symlink:

и создать новый:

и снова пробуем выполнить:

SQL Developer, Oracle XE и ORA-12705 в Linux

При попытке настроить Jasper Reports Integration столкнулся с этой же ошибкой при настройке соединения Tomcat. Решается путём создания » $CATALINA_BASE/bin/setenv.sh » с добавлением в него следующих параметров запуска Java:

У меня содержимое файла выглядит так:

Проблемы с external job (sjsec 6a)

В какой-то момент стал получать ошибку:

Это происходило в Oracle, установленном на сервер под управлением Windows.
Решение — убедитесь и при необходимости запустите сервис OracleJobScheduler .
Где SID — SID вашего экземпляра БД.

ORA-01075 you are currently logged on

Нашёл решение здесь, но решил у себя продублировать. Итак, если при подключении к БД получаем что-то типа:

нужно выполнить следующие шаги:

SQLDeveloper из Oracle 11g (64 bit) на Windows (64 bit)

При запуске sqldeveloper, который идёт в комплекте с Oracle 11G (11.2.0.4.0, 64bit) и установлен на Windows Server 2008 R2 (64 bit), получаем окно, в котором нас просят указать путь к java.exe. Однако, при указании пути к java, которая идёт вместе с Oracle или же к другой java 64 bit, ничего не происходит, кроме того, что снова появляется это же окно.
Если же пытаемся запустить » %ORACLE_HOME%sqldevelopersqldeveloperbinsqldeveloper «, то при указании пути к java получаем сообщение:

Как ни парадоксально, но это решается установкой java 32-bit и добавлением в файл » %ORACLE_HOME%sqldevelopersqldeveloperbinsqldeveloper.conf » строки, в которой с помощью SetJavaHome задан JAVA_HOME (путь к java), например так:

ORA-00845: MEMORY_TARGET not supported on this system

На Windows я с такой ошибкой пока не встречался, а на linux решение простое:

Где:
size — размер больше или равен объёму выделяемой для всех экземпляров Oracle памяти. В нашем случае он равен 12Gb (size=12g).

должны получить что-то похожее на следующее:

ORA-12034: materialized view log on «SCHEMA».»MVIEW» younger than last refresh

Можно смотреть ноту 204127.1 на Metlink.
В некоторых случаях помогает:

Проблемы при повторной конфигурации Oracle XE.

Один из вариантов повторной конфигурации Oracle XE заключается в удалении » /etc/sysconfig/oracle-xe » (для Red Hat) и выполнении » /etc/init.d/oracle-xe configure «. Однако, если у вас имеется созданное вами табличное пространство в указанном вами файле данных, выполните обязательно бэкап этого табличного пространства. Указанный скрипт выполнит пересоздание DBID для известных ему файлов данных, но не тронет те, что вы создали. Таким образом, после старта системы вы не сможете ни получить доступ к вашим файлам, ни подключить их к БД, т.к. в них прописаны старые DBID. Будьте внимательнее.

ORA-01704: string literal too long

При работе с Oracle через JDBC, столкнулся с проблемой в виде ошибки «ORA-01704: string literal too long». Оказывается, в некоторых случаях (JDBC — один из них) нельзя просто взять и вставить строку длиной больше 4000 символов в поле таблицы. Даже если это поле типа CLOB. Т.е. не прокатывает строка вида:

Пересоздание сессии в удалённой БД (dblink)

Разработчики стали жаловаться, что, при обращении к объекту, размещённому в удалённой БД, через database link, появляется следующая ошибка:

В результате, на требуемом нам сервере будет создана новая сессия. Проблема была решена. Такой вот lifehack.

К сожалению, воспроизвести ситуацию уже невозможно, но, вероятно, могла помочь и следующая последовательность действий:

Certificate of the remote server does not match the target address.

Эта заметка относится к Oracle Database 12.2.
В wallet-файле есть необходимый сертификат, но при обращении к ресурсу получаем ошибку:

» habrahabr.ru » и есть то значение, которое необходимо подставить:

Ещё один широко известный в узких кругах ресурс:

ORA-27369: job of type EXECUTABLE failed with exit code: 274662

Если при выполнении shell-скрипта, вызываемого посредством scheduler job’а с типом «external», вы получаете » ORA-27369: job of type EXECUTABLE failed with exit code: 274662 «, проверьте » $ORACLE_HOME/rdbms/admin/externaljob.ora «. Параметры run_user и run_group должны соответствовать пользователю и группе от чьего имени запущен oracle.

ORA-00392: log 1 of thread 1 is being cleared, operation not allowed

При открытии БД с resetlogs получаем ошибку:

Вероятно, первая команда » alter database open resetlogs » завершилась неудачно и в control-файле redo остались в статусе CLEARING/CLEARING_CURRENT:

Можно попробовать использовать следующие команды:

а затем уже повторить:

На metalink есть документ (Doc ID 1352133.1)

Ora 00907 отсутствует правая скобка

Всем привет!
Я сегодня с вопросом.
1. Решил оптимизировать одну свою процедуру. Выделил из запроса один сложный древовидный select с несколькими джойнами во вьюху, к которой потом обращаюсь из запроса несколько раз. Думал этот select во вьюхе отработает один раз, и потом во внешнем запросе джойниться будет результат работы этой вьюхи. Да не тут-то было! Смотрю план, а там, как было в запросе 3 обращения к этой вьюхе, так и джойнятся 3 точных копии плана этой вьюхи.

2. Когда-то раньше на одном из серверов той же версии смотрел планы запроса типа

with subquery as (select . )
select .
from subquery sq1
. join subquery sq2
on .

и в плане наблюдал скан таблицы SYS и join ее с другим сканом этой же SYS таблицы. Т.е. Oracle выполнял подзапрос subquery, результат помещал во временную им же созданную таблицу и использовал в дальнейшем ее.

3. Я попробовал переписать свой запрос аналогичным образом:

with v1 as (select * from MyView)
select .
from v1 o
. join v1 r
on .

Сам запрос нормально отрабатывает и возвращает нужные данные, а вот при команде показать план, сервер ругается:
ORA-00604: ошибка на рекурсивном SQL-уровне 1
ORA-00907: отсутствует правая скобка

Завтра на работе попробую запрос на других серваках, возможно у них настройки какие-то другие, и где-то может и план построится и построится по-другому. Может быть. Но интересно, что, какие параметры влияют на построение плана как в п.2? Может кто знает?
Да. Покопался еще в хинтах, показалось, что NO_MERGE может подойти. Но ничего не изменилось.

Версия: Oracle 9.2.0.6

Попробовал еще на 2-х аналогичных серверах. Результат тот же с точностью до миллилитра!

Я может не очень въехал в вопрос, но я обычно стараюсь «деревяшку» сделать подзапросом и джоинить уже результат этого подзапроса.
Типа
Select * from
(select * from t1 start . connect by. ) s,
t2,t3
where s.id=t2.id.

вьюхи очень плохо оптимизируются, Оракл почему-тоне умеет нормально с ними планы строить 🙁
если в ХП хочешь что-то оптимизировать, сделай вложенные FOR x IN( select. )

Короче рыл, рыл и нарыл. Все то же самое обнаружили уже многие, но в патчах этого похоже еще почему-то не поправили. Т.е. если употребляется with sq, в нем любой outer join (c inner join баг не проявляется) и во внешнем селекте джойнятся 2 и более этих sq, то при explain plan видим ошибку 604 и 907.

> Sergey13 © (28.11.05 10:01) [2]

У тебя деревяшка используется 1 раз, у меня 2 и более.

> если в ХП хочешь что-то оптимизировать, сделай вложенные
> FOR x IN( select. )

какой FOR? Мне на клиента НД надо вернуть. Т.е. должен быть результирующий select.

Ну и почему вьюху решил? Потому что этот запрос используется из нескольких мест. Я не заметил, что вьюха как-то плохо оптимизируется. Когда делаю select * from MyView . join MyTableN on . видно, что оптимизатор джойнит эту MyTableN где-то в середине джойнов, присутствующих во вьюхе, т.е. query transformation нормально отрабатывает. Ну а мне потребовалось, чтобы select во вьюхе отработал один раз, а потом этот результат несколько раз джойнился. Т.е. в плане присутствовала строка TEMP TABLE TRANSFORMATION и RECURSIVE EXECUTION. О, как это называется.
Вывод. Использую значит with v1 as (select * from MyView) select * from v1 o . join v1 r on . Только во вьюхе на время отладки плана меняю все outer join на inner, после отладки возвращаю outer. Сам-то запрос нормально отрабатывает!