Where did the Partitions and SubPartitions go?

Question

I created a table with partition Range (Transaction_Date, Retention_Period) and hash (Record_Id) subpartition template (for 32 subpartitions)
Then I add more partitions and while the loop is going on I can get counts of partitions and subpartitions. The job finished and my log table shows about 1800 partitions added and there should be 32 subpartitions for each of the partitions. However, user_tab_partitions shows zero records for the table, and user_tab_subpartitions also show zero record. After a few minutes the partitions show up but no subpartitions. The indexes on the table have also disappeared (one local and one global)
Any explanation for this behaviour?
Working on Exadata 11.2.0.3
Querying
USER_TABLES
USER_TAB_PARTITIONS
USER_TAB_SUBPARTITIONS
USER_INDEXES

Answer 1

>
Step 1. Create Table xyz (c1 date, c2 integer c3 integer, etc)
partition by range (c1,c2)
subpartition template (s01, s02... s32)
create index i1 on xyz (c1,c2,c3) local;
Then, since I want to create about 1800 partitions I have a procedure that has a "loop around" ALTER TABLE add Partition .. until all the partitions are created. This is the "Job" which while running I query USER_TAB_PARTITIONS and USER_TAB_SUBPARTITIONS to see how things are progressing. And Yes ALTER Table has no progressing to verify.
So al the partitions get created. No errors from the procedure to go through creating all the partitions. So I would expect that at the end I should get to see all the new partitions for the Table. Instead I get "no records" from USER_TAB_PARTITIONS and USER_TAB_SUBPARTITIONS.
I am also aware that "ALTER TABLE ADD PARTITION .." cannot make indexes go away. However, if the query on USER_INDEXES returns nothing, what happend to the Index created before the partitions were added?
I am not using DBMS_REDEFINITION. The only procedure is to add partitions one at a time for each date for 3 years. If you have a better way than a procedure please advise accordingly.
>
In order to help you the first step is to understand what problem you are dealing with. Then comes trying to determine what options are available for addressing the problem. There are too many times , and yours may, or may not, be another one, where people seem to have settled on a solution before they have really identified the problem.
Anytime someone mentions the use of dynamic SQL it raises a red flag. And when that use is for DDL, rather than DMl, it raises a REALLY BIG red flag.
Schema objects need to be managed properly and the DDL that creates them needs to be properly written and kept in some sort of version control.
Scripts and procedures that use dynamic SQL are more properly used to create DDL, not to execute it. That is, rather than use a procedure to dynamically create or alter a table you would use the procedure to dynamically create a DDL script that would create or alter the table.
Let's assume that you know for certain that your table really needs to have 1800 partitions, be subpartitioned the way you say and have partition and subpartitions names that you assign. Well, that would be a pain to hand-write 1800 partition definitions.
So you would create a procedure that would produce a CREATE TABLE script that had the proper clauses and syntax to specify those 1800 partitions. Your 'loop' would not EXECUTE an ALTER TABLE for each partition but would create the partition specification and modify the partition boundaries for each iteration through the loop. Sort of like
for i from 1 to 365 loop
    add partition spec for startDate + i
end loop;The number of iterations would be a parameter and you would start with 2 or 3. Always test with the smallest code that will produce the correct results. If the code works for 3 days it will work for any larger reasonable number.
Then you would save that script in your version control system and run it to create the table. There would be nothing to monitor since there is just one script and when it is done it is done.
That would be a proper use of dynamic sql: to produce DDL, not to execute it.
Back to your issue. If I were your manager then based on what you posted I would expect you to already have
1. a requirements document that stated the problem (e.g. performance, data management) that was being addressed
2. test results that showed that your proposed solution (a table partitioned the way you posted) solves the problem
The requirements doc would have detail about what the performance/management issues are and what impact they are having
You also need to document what the possible solutions are, the relative merits of each solution and the factors you considered when ranking the solutions. That is, why is your particular partitioning scheme the best solution for the problem.
You should have test results that show the execution plans and performance you achieved by using a test version of your proposed table and indexes.
Until you have 'proven' that your solution will work as you expect I wouldn't recommend implementing the full-blown version of it.
1. Create a table MANUALLY that has 2 or three days worth of partitions.
2. Load those partitions with a representative amount of data
3. Execute test queries to query data from one of those partitions
4. Execute the same test queries against your current table
5. Capture the execution plans (the actual ones) for those queries. Verify that you are getting the performance improvements that you expected.
Once ALL of that prep work is done and you have concluded that your table/index design is correct then go back to work on writing a script/procedure that will produce (not execute) DDL to produce the main table and partitioning you designed.
Just an aside on what you posted. The indexes should be created AFTER the table and its partitions are created. If you are creating your local index first, as you post suggests, you are forcing Oracle to revamp it 1800 times when each partition is added. Just create the index after the table.
p.s. the number of posts anyone has is irrevelant. The only thing that matters is whether the advice or suggestions they provide is helpful. And the helpfullness of those is limited to, and based on, ONLY the information a poster provides. For exampe, your proposed partitioning scheme might be perfectly appropriate for your use case or it could be totally inappropriate. We have no way of knowing without knowing WHY you chose that scheme.
But I haven't seen one like that so it makes me suspicious that you really need to get that complicated.