Re: ora-01555 on 7.3.4.5

With Oracle's ocopy executable you can copy the open file. It's there for hot backup's.
When you do it on a moment you don't expect access to the file, you can try dbverf already before - and most likely on a much more appropriate time of the day - then next planned downtime. The risk is a false alarm because it was modified during copy.

Can't you restore a backup of the database on an other server so you can freely experiment?
If the db is too big, only restore files of system, temp, rollback, the problem table tablespace and if possible the problem table index tablespaces. From a "backup controlfile to trace" made on the original database you make a create controlfile with only the files you restored. With this controlfile you can start the restored and stripped database and make temp and rollback smaller for convenience. The moment you access objects not in the files you kept, you will get the stranged errors ofcourse. So just don't do that.

Just some ideas.

Martin Dohse <mdohse_at_web.de> schreef in berichtnieuws 3D693DFC.9000500_at_web.de...
| Anton Buijs wrote:
| > Is the database been stopped and started since the problem occurs?
| yes
|
| > a. analyze table X validate structure;
| done - same error; we too did an alter session set events to increase
| the error level, that led us to another inaccessable data block and - by
| examining the trace - to another problem, that we have 'malformed'
| data in some datasets (f.e. we found an attribute containing more bytes
| than it should have or 'corrupted' date strings)
|
| > b. use the dbverify utility for every file the table and its indexes
have
| will be next step at an allready planned downtime- unfortunately
| dbverify on nt is not possible while the datafile is accessed...
|
| martin
|
Received on Sun Aug 25 2002 - 16:20:56 CDT