Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.databases.oracle    |    Overblown overpriced overengineered SHIT    |    2,288 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 1,315 of 2,288    |
|    Hans Forbrich to All    |
|    Re: Dumb story short- need to recreate f    |
|    20 Apr 04 17:43:06    |
      From: forbrich@yahoo.net              D wrote:              > Oracle 8.1.7 on solaris.       >       > This involves one schema. The data dictionary can be read, but there       > are other sys tables and views that have problems. Some of the errors       > come from the previous, now fired, dba screwing up the transfer from       > the 32-bit version to the 64-bit version- those are the errors I'm       > getting. I am not a maintenance dba- I'm a programmer who designs his       > own databases. It would not surprise me that I missed something       > obvious you can do with system files in oracle, but not sqlserver or       > DB2, etc.       >       > DBA created new database by creating a script written in perl that       > pulled out the structure of the db only and not the constraints. also       > pulled out the data and inserted the data. The scripts I have to       > generate the table are not up to date enough to recreated the       > database- too many changes in this development system.       >       > So I have the correct structure and the correct data but no       > constraints. I can view all the constraints in TOAD which probably       > means if I could write or better yet find, a statement to select what       > I need from the system table that manages constraints then that is       > what I need to find.              Oracle uses views such as DBA_TABLES, DBA_CONSTRAINTS and so on to make the       dictionary available.              The scripts to (re)create these views should be found in       $ORACLE_HOME/rdbms/admin - usually catalog.sql              It's not unusual for DBAs to miss running the script after an upgrade, or       fail to look at the result file after running the script or even missing       legit errors when looking at the output. (The output frequently has many       errors listed, mainly "failed to drop non-existant objects")              Sounds like the upgraded source DB is only mildly insane - you may want to       check some of the DBA_ views against the catalog.sql script, esp. those       related to the constraints. If not in sync, then consider rerunning       catalog.sql              /Hans              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca