Markus was basically right although tablespaces are indeed not the same as data volumes.
Tablespaces of other DBMS are administrative units of abstraction for data storage space.
Each tablespace consists of one or more files where the data is finally stored to.
Tablespaces are all about to ease the handling of db storage.
For MaxDB you could either say that it does not support tablespaces at all, or that it supports only one tablespace. The outcome is the same: there's no additional abstraction layer between database segments/storage objects and the files.
With MaxDB all data is just put into the Data Area, which is formed by all available data volumes.
Concerning your
> A volume contains many tables... but the table has it's own space.
> I cannot get a bigger table space when I increase the amount of volumes.
I'm a bit unsure what you want to say with that.
In MaxDB when you add a new data volume you do have more space to store data to.
Hence your tables (all of them) can grow further, until all freespace is allocated again.
By the way: one of the reasons for which tablespaces are a nice thing to have in other DBMS is that data there is placed in a fixed location.
Given that you can e.g. just recover one tablespace and get the segments stored in that tablespace consistent again. From a general relational DB perspective this is of course nonsense, since consistency has to be defined over the whole database - but there are several scenarios where this still can lead to valid results.
MaxDB always spreads the data over all available volumes evenly. There's no way to prevent this. Anyhow, it means that you need to touch all data of the database to recover an instance.
That's one of the reasons why MaxDB backup is not at all file/volume based, but page based.
Hope that helps a bit to grasp the different concepts.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.