I need to know what data needs to be dumped and loaded to save and restore Partition Policies. A couple of ESAP drops ago, I believe that there were only _Partition-Policy and _Partition-Policy-Detail tables. How are the _Partition-Set and _Partition-Set-Detail tables used?
The _Partition-Policy and _Partition-Policy-Detail tables store the partition policy definitions and can be dumped and loaded as .d files. Note that this does not include the physical allocation of partitions, which are stored in the _StorageObject with one record for the table and each index and lob field. The _StorageObject records will be created based on the default allocation rule and default areas of the loaded _Partition-policy-detail
The corresponding DataAdmin API interfaces, IPartitionPolicy and IPartitionPolicyDetail, have ExportTree and ImportTree methods that export and import the data as json and can also include the physical partitions. One benefit of using the API is that you can dump and load subset of data and that the load can be done in one transaction. The drawback of these methods is that there is no code page support.
Another way to store(backup) and load the policies is to use the option to generate a partition policy as code and then run the code to load the policies.
These two tables are used for Multi Tenant Groups.
Yes, I noticed the description in the tables, but do these tables have anything to do with table partitioning on field values, or are they used strictly for grouping of tenants in a multi-tenant configuration?
The _Partition-Policy and _Partition-Policy-Detail tables store the partition policy definitions and can be dumped and loaded as .d files. Note that this does not include the physical allocation of partitions, which are stored in the _StorageObject with one record for the table and each index and lob field. The _StorageObject records will be created based on the default allocation rule and default areas of the loaded _Partition-policy-detail
The corresponding DataAdmin API interfaces, IPartitionPolicy and IPartitionPolicyDetail, have ExportTree and ImportTree methods that export and import the data as json and can also include the physical partitions. One benefit of using the API is that you can dump and load subset of data and that the load can be done in one transaction. The drawback of these methods is that there is no code page support.
Another way to store(backup) and load the policies is to use the option to generate a partition policy as code and then run the code to load the policies.
>> The drawback of these methods is that there is no code page support.
Note that the classes use the ABL's json support which uses UTF-8, so this should in theory not be a problem.
Thanks for the detailed response. I also noticed the new APIs. It's good to know that I still have a pretty good understanding of table partitioning. The other table names (_Partition-Set and _Partition-Set-Detail) had me thinking that there was now another layer to Table Partitioning that I needed to catch up on.
"Those 2 are only for Multi-tenant groups"
Thanks. The presence of the word "Partition" in the other table names (_Partition-Set and _Partition-Set-Detail) had me thinking that they had something to do with Table Partitioning. Apparently, it's another kind of partition (?).
On 6/19/14 2:23 PM, "randallkharp"
wrote:
>Apparently, it's another kind of partition (?).
correct.
multitenant table partitions are based on owning tenant's identity
11.4 table partitions are based on values present in the data
--
regards, gus
alien developer, progress software
"Culture eats strategy for breakfast." -- Peter Drucker