Discussions
Categories
- 196.7K All Categories
- 2.2K Data
- 234 Big Data Appliance
- 1.9K Data Science
- 449.8K Databases
- 221.5K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 549 MySQL Community Space
- 477 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 532 SQLcl
- 4K SQL Developer Data Modeler
- 186.8K SQL & PL/SQL
- 21.2K SQL Developer
- 295.3K Development
- 17 Developer Projects
- 138 Programming Languages
- 292K Development Tools
- 104 DevOps
- 3.1K QA/Testing
- 645.9K Java
- 27 Java Learning Subscription
- 37K Database Connectivity
- 153 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 17 Java Essentials
- 157 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 203 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 389 LiveLabs
- 37 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.6K Other Languages
- 2.3K Chinese
- 170 Deutsche Oracle Community
- 1K Español
- 1.9K Japanese
- 230 Portuguese
Is it OK to drop Invalid Objects that have a Referenced_Owner/Referenced_Name? (dba_dependencies)

I attempting to clean out my Oracle 18c databases of Invalid Objects. I was given the go ahead from the developers to remove a few invalid objects but after googling, I noticed that I would have to watch out of other dependent objects.
If I drop these invalid objects would it have any effect on the referenced objects. Would it turn those invalid as well, creating more invalid objects? I already attempted to recompile and got compilation errors. I sent them to the application owners (Developers) and they said I can remove the objects. Below I provided the Invalid objects and the referenced objects to them. How should I clean out the invalid objects?
INVALID OBJECTS **[OWNER / OBJECT NAME / OBJECT TYPE]**
PLAP/TEMP_DIS_CONSTR/PROCEDURE
PLAP/TEMP_DRP_CONSTR_PK/PROCEDURE
PLAP/TEMP_UPDATE_MILESTONE_TABLE/PROCEDURE
INVALID OBJECTS -----> REFERENCED OBJECTS
PLAP/TEMP_DIS_CONSTR/PROCEDURE -------> SYS/ALL_CONS_COLUMNS/VIEW
PLAP/TEMP_DIS_CONSTR/PROCEDURE -------> PUBLIC/DBMS_OUTPUT/SYNONYM
PLAP/TEMP_DIS_CONSTR/PROCEDURE -------> SYS/STANDARD/PACKAGE
PLAP/TEMP_DRP_CONSTR_PK/PROCEDURE ------> SYS/STANDARD/PACKAGE
PLAP/TEMP_DRP_CONSTR_PK/PROCEDURE ------> PUBLIC/DBMS_OUTPUT/SYNONYM
PLAP/TEMP_DRP_CONSTR_PK/PROCEDURE ------> PLAP/AOP_CAPABILITY_MILESTONES/TABLE
PLAP/TEMP_UPDATE_MILESTONE_TABLE/PROCEDURE ------> SYS/STANDARD/PACKAGE
PLAP/TEMP_UPDATE_MILESTONE_TABLE/PROCEDURE ------> PLAP/AOP_MILESTONES_SEQ/SEQUENCE
Thanks
Answers
-
You only have to worry about objects that reference the invalid objects (directly or through other dependencies), not objects that the invalid objects reference (caveated that they are not referenced by another invalid object).
E.g. Dropping PLAP/TEMP_DIS_CONSTR/PROCEDURE, won't affect SYS/ALL_CONS_COLUMNS/VIEW
-
That depends...
Some of those invalid packages/procedures/functions/views may need to have their code changed so that they may be used later on. So, I don't think it is the case to rush into such spring cleaning. First use dbms_utility.compile_schema(x_schema,false) to see what can recompile, then send all the developers you know to be working on that database a list of the invalid objects, eventually including also the errors, with the warning that, if in within two weeks they won't fix them, then they will be dropped.
Yet, if your concern is space, tables are those that take most of the space.
-
Thanks so much! That's exactly what I did. First I tried to see what invalid objects I could recompile (except I used @utlrp.sql). Then, I sent all the developers a list of the invalid objects with each error included so that they can look through and fix the code if need be.
-
Thanks for the clear and concise answer Paulzip! This is exactly what I needed to know!