In article <367ad897.8263093_at_news.siol.net>, Jurij Modic <jmodic_at_src.si>
writes
>On Fri, 18 Dec 1998 16:00:48 +0000, Greg <greg_at_orell.co.uk> wrote:
>
>>Okay, so I'm not an Oracle expert yet. However, I, or someone else
>>managed to create a whole lot of tables that I don't want in my
>>tablespace. I think it has to do with launching the Enterprise Manager.
>>I am using NT.
>>
>>The tables I don't want consist of
>>
>>EVT_CARRIER_CONFIGURATION
>>EVT_DEST_PROFILE
>>...
>>SMACTUALPARAMETER_S
>>SMAGENTJOB_S
>>...
>>SMP_AD_ADDRESSES_
>>SMP_AD_DISCOVERED_NODES_
>>...
>>
>>These tables are already in the SYSTEM tablespace. That's okay, but they
>>don't need to be in my tablespace (at least I don't think so).
>>
>>Someone please shed light...
>
>Well, to be strict, those tables should not be put in SYSTEM
>tablespace either! They sholuld be in some other tablespace, like
>TOOLS for example.
>
>How to get rid of them easily - well, it depends on the release of OEM
>you are using. On more recent releases (like 1.3.* and up) there
>should be a program in an OEM profile folder called something like
>"Removing OEM Repository" (I dont have OEM instaled here so I'm not
>sure about the exact name of this beast). On earlier releases (like
>1.2), you can run two scripts from (default instalation)
>X:\ORANT\SYSMAN\ADMIN - the scripts are named SMPDRP.SQL and
>PERFDRP.SQL (the later is used for removing tables used by performance
>pack components).
>
>>Greg
>
>HTH,
>
>Jurij Modic <jmodic_at_src.si>
>Certified Oracle7 DBA (OCP)
>================================================
>The above opinions are mine and do not represent
>any official standpoints of my employer
By the way they are created by someone running the enterprise manager
console and connecting as the wrong user or to the wrong database -
apparently Enterprise manager 2 does not do this but queries if you try
to connect to somewhere other than the enterprise repository database.
The guys where I work keep doing this and I keep dropping the tables - I
have a dynamic bit of SQL to do it - luckily the names don't match any
legitimate tables (yet!)
--
Diane
Received on Sun Dec 20 1998 - 15:07:40 CST
