This content has been marked as final. Show 1 reply
So don't use it. Disable it if you'd like to be be sure the web pages won't be accessed, quickest way to whack apex is remove the shared server parameters.
I don't want to use apex
I'm pulling those out from memory, one/the other/or both might be 'alter database ...'. Try 'em, if it gripes, try ' ... database'.
sqlplus /nolog connect system ... password ... connected. alter system reset dispatchers scope=spfile; alter system reset shared_servers scope=spfile; -- and bounce to enforce changes and make sure spfile is good conn /as sysdba; shutdown immediate; startup;
That's one of the recommended ways, schema export/import. The full 11g documentation, the Utilities book, has the details. If tablespace(s) and/or schema name(s) need adjustment on the impdp end, or exclude some objects, or just include a subset of objects, there are options to specify what goes where and what gets imported.
should I just use impdp ... get the schema(s) I want?
I never use exp/imp or datapump full=y for anything, it can muck just about anything in a database instance outside of the sys/system catalogs if not done with care. One or three schemas at a time is a good approach, although I've seen folks trying to expdp over 1,000 schemas in one pass. Yuck. I'd use a tablespace transport for that chore. Doesn't take much longer than copying the datafiles over the network, if the source and target OS both use the same endian-ness CPU.
Those are schemas and roles used by the oracle agent and dbsnmp schema for instance health monitoring, maybe no harm done if you're not using the agent or don't have an OMS. I suppose those schemas could be dropped, but I think sysman could have some memory or other internal monitoring/health check/tuning chores, MMAN, MMON processes, perhaps? I'm not positive.
sysman ...mgmt_view ... errors
Nope, if you're not using apex, in that case workspaces are not relevant.
application to connect to the database ... create a workspace ...?