home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / database / oracle / 1133 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  2.0 KB
  1. Path: sparky!uunet!gatech!destroyer!gumby!yale!yale.edu!jvnc.net!netnews.upenn.edu!uofs!jaguar.uofs.edu!littlec1
  2. From: littlec1@jaguar.uofs.edu (Chris Little)
  3. Newsgroups: comp.databases.oracle
  4. Subject: Re: DB file not in DBA_DATA_FILES - problem
  5. Message-ID: <1992Jul24.144017.1@jaguar.uofs.edu>
  6. Date: 24 Jul 92 19:40:17 GMT
  7. References: <1992Jul21.112252.1@jaguar.uofs.edu> <1992Jul22.180853.24460@oracle.us.oracle.com>
  8. Sender: news@uofs.uofs.edu
  9. Followup-To: kjou@oracle.com
  10. Organization: University of Scranton
  11. Lines: 39
  12. Nntp-Posting-Host: jaguar.ucs.uofs.edu
  13.  
  14. > I would venture to guess that something is inconsistent in the data dictionary.
  15. > If it is at all possible, then the safest action is to recreate the tablespace 
  16. > from an export of the objects that currently reside in it.  Does the control 
  17. > file still recognize this datafile?
  18.  
  19. No.  I did a dump of the control file to determine that.
  20.  
  21. > How did you determine that DBWR is 
  22. > accessing that datafile which was not successfully added?
  23.  
  24. On VMS I did a $ SHOW DEVICE/FILE {device-name}, 
  25. where {device-name} is the name of the disk on which the database files reside.
  26. This command tells what files are being accesses and by what processes.
  27.  
  28. > Did you perform
  29. > the add datafile operation again, using the same datafile name?
  30.  
  31. Yes, but I got an error saying that that filename already was being used
  32. by the database.
  33.  
  34. >If the 
  35. > control file and dba_data_files match, then things should be OK.
  36.  
  37. This indeed is the case.  I shut down the instance and brought it back up again.
  38. This eliminated the DBWR process that was accessing the file, so I was then
  39. able to delete the file.  I wonder what would have happened if I just killed
  40. that process at the VMS level, without shutting down the instance.
  41.  
  42. > Kathy Jou
  43. > Oracle Corporation
  44. -- 
  45.  
  46. Thank you, Kathy.
  47.  
  48. --
  49. Chris Little, Programmer/DBA
  50.                                                 University Computing Systems
  51.                                                 University of Scranton
  52.   LITTLEC1@JAGUAR.UOFS.EDU                      Scranton, PA 18510
  53.