По ошибке мы создали несколько лишних файлов данных для табличного
пространства, например PSAPDEV, но потом вовремя спохватились и перевели файлы в режим OFFLINE.
Но теперь brconnect мучает нас сообщениями о файлах в статусе OFFLINE,
которые нам собственно говоря уже не нужны и их вообще уже нету:

PSAPDEV ONLINE+ /oracle/DEV/sapdata2/dev_13/dev.data13 OFFLINE
ERROR, type: FILE_OFFLINE, object:oracle/DEV/sapdata2/dev_13/dev.data13

Что надо сделать, чтобы система навсегда "забыла" об этих файлах?

p.s. разумеется есть грубые решения, типа деактивировать эту проверку через DB17, но этого делать сильно не хочется. Такой же вопрос я задавал в службу поддержки SAP - их ответ "это стандартна реакция системы и делать ничего не рекомендуется". Я же думаю, что надо "почистить" таблицы где эти файлы прописались...

Да ничего страшного в этих сообщениях нет.Файлы прописаны не в "таблицах", а в controlfiile БД Oracle.Можно экспортнуть controlfile , вынести там записи об этих файлах,и стартовать базу с reuse control file(1-й путь камикадзе), однако в словаре базы могут сохраиться записи об объектах из этих файлов, если таковые имеются.
Убирать проверку в DB17 думаю не стоит, просто принять как должное напоминание от системы о том, что сначала надо думать, а потом делать.Кстати не факт, что через какое-то время вам не понадобилось бы добавить датафайлы именно в это табличное пространство,и тогда достаточно было бы перевести датафайлы в online статус, но как я понял вы уже удалили датафайлы на уровне OC(видимо нехватка дискового пространства).
Ну а если уж совсем невтерпеж то есть еще 2-й путь камикадзе:( но думаю опять же не стоит заморачиваться):

Doc ID: Note:161798.1
Subject: How to Drop Datafile Added by Mistake?
Type: HOWTO
Status: PUBLISHED

Content Type: TEXT/X-HTML
Creation Date: 12-JUL-2001
Last Revision Date: 02-OCT-2003

* goal: How to Drop Datafile added by mistake?
* fact: Oracle Server - Enterprise Edition



fix:

You cannot drop individual datafiles.

If the tablespace contains recreatable objects eg indexes, then
1) offline the tablespace
2) drop the tablespace includiing contents
3) recreate the tablespace
4) recreate the objects

If the tablespace contains tables

1) export all the objects in the tablespace
2) drop & recreate the tablespace as above
3) import the objects

Workaround

It is possible to resize the datafile to 1K. Then no objects should get created
in the datafile (although it must still form part of your backup).

В 10-ке вроде бы обещают включить возможность удаления отдельных датафайлов.
Удачи

В принципе решение предложил Lammer.
Однако способы реализации могут быть различными:
1. Пересоздать табличное пространство средствами Oracle (exp, imp, sqlplus);
2. Провести реорганизацию табличного пространства средствами BRTOOLS.

я думаю, что реорганизация табличного пр. через BRTOOLS самый простой способ. Спасибо за совет...

В данной конкретной ситуации, когда имеются оффлайн-файлы да к тому же физически удаленные, BRTOOLS и exp будут материться как не в себе и ничего не получится.

Проще как прелагал Lamer - через control файл.

Я перепроверил, файлы еще мы не удалили. Только я не понял, если они в статусе offline реорганизацию tablespace сделать невозможно?

Переведи в online и реорганизаци пройдет

а /oracle/<SID>/sapreorg должен быть какого размера?
такого же, как и реорганизуемое табличное пространство?

А прога сама тебе посчитает - сколько потребуется пространства