after looking through all the documentation and tutorials about multitenancy I still cannot find an (satisfying) answer to how define the mapping of tables/indexes to areas when creating a new tenant.
there is the option to choose 3 default areas for a new tenant (for tables,indexes,lobs). But we have set up the schema with lots of different areas using different RPB settings, cluster sizes and so on (about 500 Tables and 30 areas).
From working through the documentation it seems that using the tenant template functionality in data administration seems to be the right way to set this up. But that looks like an awful lot of work, essentially duplicating work that I already did when setting up the DB. Another possible solution might be to use the ABL tenant API, but that seems to have no interface to create/maintain templates...?
Maybe it would make more sense to use the API and loop through the metaschema when creating a new tenant, and then setting the area for all tables/indexes using the tenant-partition interface..?
Any suggestions? Am I missing something here?
Mike
Not quite sure how things will evolve in coming versions of Progress, but from an administrative point of view, things might get easier if you migrate to a smaller set of areas. I think for over 90% of the cases it is not needed to have an enormous set of areas, varying in RPB and cluster size. What if you just switch all data to 64 RPB? On an 8K blocksize database that would mean that all records could take up to approx 120 bytes. In the past there used to be a large trade-off for maximum nr of records and RPB but that's gone, so why would you want to have areas with all different kind of RPB settings?
Once you have a smaller set of areas, creating new areas for new tenants is also a lot easier.
A couple of years ago at Progress Revolution, Rich Banville and Edsel Garcia gave a session on multi-tenant administration. They did touch on storage area design considerations and the trade-offs of each. You might find it helpful.
http://download.psdn.com/media/revolution_2011/oe13/OE1305.wmv
Thanks a lot for sharing. That presentation covers the partitioning stuff very detailed and helps a lot.
It really seems that one should go with the simple "one area per object type (table/index/lob)" strategy...