BGT schreef:
> On Mar 1, 1:07 pm, "BGT" <bgt0..._at_optonline.net> wrote:
>> On Feb 28, 2:39 pm, "joel garry" <joel-ga..._at_home.com> wrote:
>>
>>
>>
>>
>>
>>> On Feb 28, 7:23 am, "BGT" <bgt0..._at_optonline.net> wrote:
>>>> I am no longer able to truncate tables in this 9.2.0.6.0 database.
>>>> When I do a "truncate table "tablename" drop storage" I get ORA-00904
>>>> "DROP SEGMENTS" INVALID IDENTIFIER.
>>>> I've tried this on multiple tables as the schema owner and a SYSDBA
>>>> user with the same results. Any idea what is happening?
>>>> Thanks
>>>> Barry
>>> Well, there was a bug in an earlier version, maybe somewhere along the
>>> line you ran the wrong catalog.sql or got an old sql.bsq.
>>> as sys,
>>> SQL> desc mon_mods$
>>> Name Null? Type
>>> ----------------------------------------- --------
>>> ----------------------------
>>> OBJ# NUMBER
>>> INSERTS NUMBER
>>> UPDATES NUMBER
>>> DELETES NUMBER
>>> TIMESTAMP DATE
>>> FLAGS NUMBER
>>> DROP_SEGMENTS NUMBER
>>> If you don't have a field named drop_segments, you have this problem
>>> (which could potentially be a quite serious patching goof). Check
>>> sql.bsq to be sure it has a create statement that matches this table.
>>> Then try running catalog.sql.
>>> jg
>>> --
>>> @home.com is bogus.
>>> Are they still using Sybase? http://www.kstp.com/article/stories/S33513.shtml?cat=1
>> I tred to send this before but Google ate my msg.
>>
>> Joel is correct I don't have a DROP_SEGMENTS entry in that table. I
>> checked the sql.bsq script and the correct entry is there for this
>> table, but running Catalog.slq did not bring it back. I manually
>> entered the column into the mon_mods$ table and I am running catalog
>> again to see if it wacts any different.
>>
>> Thanks
>> Barry- Hide quoted text -
>>
>> - Show quoted text -
>
> That took care of the problem. The question is how did it happen in
> the first place? I believe that this database was the second on on
> this box and was added via the Database Configuration Assistant I
> believe it was patched before the database was added.
>
> Barry
>
Then that could have been your cause - you have used a pre-configured
database (that is, NOT the custom, but one of the three db types that
come *with* datafile), but the jars, containing the datafiles are not
patched when rolling out the patch.
Basically you ran a 9.2.0.2 database on a 9.2.0.6 software tree.
If this is so, you may consider to run the patch instruction by this
instance once more.
--
Regards,
Frank van Bortel
Top-posting is one way to shut me up...
Received on Thu Mar 01 2007 - 13:02:48 CST
