Hi, We're trying to setup a Multi Tenant database (I'm new in this). We've created a database according to the video's and whitepapers on the progress-site (with a .st -file). We could enable the database as Multi-tenant and create tenants. But when I select 'Enable Multi Tenancy for Tables', I can't select any table. They all are in Type I storage. The .st file that i used is the following : # b c:\D-Plan\db\ # d "Schema Area":6,32;1 c:\D-Plan\db\ d "Data":7,64;8 c:\D-Plan\db\ d "Indexes":8,64;8 c:\D-Plan\db\ # Additional Area Storage for tenants d "T1":101,64;8 c:\D-Plan\db\ d "T2":102,64;8 c:\D-Plan\db\ d "T3":103,64;8 c:\D-Plan\db\ d "T4":104,64;8 c:\D-Plan\db\ d "T5":105,64;8 c:\D-Plan\db\ Can someone point me what I'm doing wrong here and how I can enable the tables for Multi-tenancy ? Kind regards, Bart Syryn
Ok, thanks for all the replies.
If you want to enable multi-tenancy for a table, it SHOULD be in Type II area
Ok, but how I load the .df file in a Type II area ? Is my .st-file incorrect ?
I've looked in the knowledge base, but tablemove doesn't work, it gives me the error that the area doesn't exist ?
Flag this post as spam/abuse.
Your .st file is correct.
Make sure that you have enabled multi-tenancy for the database:
proutil dbname -C enablemultitenancy
If you are using "OpenEdge Management", you can enable multi-tenancy from "Database Features" section that appears when you click on a database connection.
If you are loading an existing .df file, modify "AREA" line (for both tables and indexes) in .df with any Type II area in your .st file:
For eg, change area line in your .df to AREA "T4"
Then, you can enable multi-tenancy for it.
ok, thanks, that did the trick.
But I see a problem with maintenance. For development we use a workgroup database. So everytime we update the database, we should manualy change the delta.df file and also manually set 'Multi tenancy' for every table we add ? Looks like something that could be forgotten.
Why do we need to define the 'shema area' in the .st file (can only be type I storage) ? Will that stay empty ?
What is best practices for Multi-tenancy. One area for every tenant ? Suppose that every tenant would be about 350Mb ?
Multi-tenant requires 11.x Enterprise RDBMS. So if you want to use MT features in your dev environment you'll need to upgrade your RDBMS license(s) and buy multi-tenant tables license(s).
I am not sure what you mean by "every time we update the database". Do you regularly replace your development database with a copy of a different database? Or are you regularly replacing some other DB with a copy of development?
Best practices will very much depend on your situation; your priorities, your needs, etc. There will be trade-offs in storage area design that you will have to make decisions about. There is no one-size-fits-all approach. These concepts are well covered in Rich Banville's session from Progress Revolution 2011:
Multi-tenant Administration - Easier Than You Thought It Would Be
http://download.psdn.com/media/revolution_2011/oe13/OE1305.wmv
Rob, thanks for the link and it helped me with the design.
We'll go for one area for data and one area for indexes for each tenant.
About the update of the database. I was meaning when you have new tables and new indexes. Then we create an incremental .df file and load that into the database. So it means that we manually need to change that .df file so that it always set the table Multi-tenant or not and also point to the correct storage area (specific for the data definition). We have clients on OE10.2A and now we're moving the application in a SaaS model on OE11.3, but need to maintain the two options.
Where do you add new tables and new indexes? Do you have two databases? If yes, what is the purpose of having two databases?
The new tables and indexes are created in a development DB.
When going online, we make incremental .df file (between development DB and Production DB). The incremental .df fille than gets loaded in the production DB. Doesn't seem bizar to me.
Ok.
As Rob pointed out, you cannot use multi-tenancy features as your development DB has only workgroup RDBMS license. So, I believe you need to do changes to delta.df everytime.
If the development DB has multi-tenant feautres, you need not do any changes. Loading delta.df to production DB works straightaway.
Ok, thanks for all the replies.
I do MT work on a PDS/OEA db, however I think that's a special case for just personal databases accessed from the development tools.