Имеется БД Oracle 9i и количество непоследовательных id около 10000.
Необходимо выполнить Select * from TBL where id in (1000, 2103, 7320, ... 21248);
Вносить изменения в БД запрещено разработчиком, можно только select. Таким образом создавать таблицы с перечнем id нельзя. Временные таблицы, насколько я понял из статьи http://www.sql.ru/blogs/oracleandsql/1373 вносят изменения: "После создания временной таблицы ее описание сохраняется в словаре данных ORACLE...".
1. Правильно ли я понимаю, что единственный выход -select id in (....., n)?
2. И тогда, какое ограничение на перечень? Где-то на форуме нашел ограничение в 1000. Так ли?
3. Слабое железо на сервере и мало памяти. Какое оптимальное количество в перечне, что бы не повесить сервер вообще и оставить небольшой запас ресурсов для других задач, хотя бы что бы сервер отвечал?
Спасибо!

Anton_Deminnnn2k,

Сформулируйте, пожалуйста, конкретнее, что вам надо?
Еженедельно присылается xml файл где содержится ~10000 разных id, по этим id надо делать выборку из БД Oracle, в которую нельзя вносить изменения - нельзя вмешиваться в структуру БД, нельзя создавать дополнительные таблицы типа "table_of_numbers". Написав запрос Select * from TBL where id in (..... 10000) он получится огромного размера и Oracle его просто не пропустит по лимиту. Создавать 10000 выборок (select * from TBL where id=1; select * from TBL where id=15; ...) - столько запросов будет выполнятся слишком долго и, наверное, подвесит сервер.

--Eugene--,
Для создания коллекции table_of_numbers придется вносить изменения в схему, чего нельзя делать по условиям.

trace.log,
id лежат отдельно в xml файле.

orawish,
Можно распределить 10'000 id по 10 запросам по 1'000 id. Всяко быстрее чем 10'000 отдельных запросов по одному id.
Много тем на эту тему, но из всего что нашел - чаще предложения о временных таблицах, что, предположительно, вносит изменения в схему и запрещено разработчиком БД.

stax..,
Справится ли слабый сервер с таким запросом или повиснет на час? В ближайшее время не могу его так протестировать. Может у Вас был опыт по времени исполнения подобного запроса.

Vint,
Вероятно это самый простой и безболезненный способ, им и воспользуюсь. Спасибо за мысль!

Спасибо всем за ответы! Использую вариант Vint'а, так как остальные возможности не подходят по условиям использования БД без изменений или вопрос с нагрузкой на БД.

Извиняюсь, совсем запутался в структуре Oracle, не часто с ним работаю.
Доп. условия: есть пользователь USER_BUH, в нем набор данных, который надо получить (select * from TBL), имея много id из xml файла.
Получается, что и схему в пользователе я не могу новую создать, так как запрет распространяется на всего пользователя. Создавать нового пользователя (USER_TMP_TBL) только ради таблицы с id номерами - не рационально, полагаю. Да и разрешения надо же сохранять внутри основного пользователя USER_BUH, в которого логинится программа оператора (сотрудника), что опять запрещено. Вероятно придется вернуться к разбивке диапазона id по нескольким выборкам (~10000 по 10-20 выборкам select).

Хотя, поразмыслив, описание временных таблиц же сохраняются в словарь Oracle, который является системным, а не пользовательским, вроде как. Остается надеяться, что это так, и разработчик БД не завернет запрос с использованием временных таблиц.

Elic,
Спасибо, это был бы замечательный вариант. Но насколько понял: xmltable ввели только в 10й версии, а у меня на производстве 9i.

Извиняюсь, ушел в работу с головой.
Сначала маялся с установкой тестового сервера 9i на Linux, в итоге - виртуалка и Win, для экспериментов над вариантами решения вопроса.
По сути: На рабочем сервере разбил 100к запросов по 10000 - 0.2-0.6 секунд на каждые 10к. Вполне приемлемо.
То что предложил Elic (xmlsequence) - тоже успешно заработало на 9i, но пришел к предположению, что парсинг xml - это опять же лишняя нагрузка на оперативку (если конечно происходит разбивка на DOM элементы), так что plain text - вероятно дешевле. Остановился на Where id in (....) с разбивкой по 10к запросов.
Спасибо всем за помощь!

*Ошибся в числах. Конечно, 100к - это 10к, а 10 000 - 1 000.