All Sybase IQ databases are preallocated, whether they reside in a file system or a raw partition.
Each database includes multiple dbspaces. A dbspace is a logical name for a database file. The Catalog Store, the IQ Store, and the Temporary Store all consist of dbspaces. The first dbspace for each store is created automatically when you create the database. You can create additional dbspaces as needed.
When you create and load a table, Sybase IQ distributes the data among all existing dbspaces in that store with any room available. You cannot control how data is distributed among the dbspaces within a store. You can reserve space for a dbspace to grow when you create it. You can resize the dbspace up to the maximum reserve. You can also make the dbspace smaller, provided that all data has been moved off of the truncated portion of the dbspace. You can move individual database objects off of specified dbspaces as needed.
If possible, do not allocate all of your disk space to your IQ database. Keep ten percent in reserve. Sybase IQ needs this space to handle out-of-space conditions gracefully.
When possible, create all dbspaces when you create the database, rather than adding them gradually as old ones become full. This approach ensures that your dbspaces will be filled more evenly, and thus helps improve disk I/O.
The amount of data, and the number and types of indexes you create, determine how much space you need in your IQ database. If you run out of space when loading or inserting into a database, Sybase IQ prompts you to create another dbspace, and then continues the operation after you add the dbspace.
In addition to any temporary tables you define explicitly, Sybase IQ uses the Temporary Store as a temporary result space for sorts, hashes, and bitmaps during loads and deletions. The types of queries issued, the degree of concurrent use, and the size of your data all determine how much space you need for your Temporary Store.
It is generally a good idea to create separate databases for debugging purposes. Because development work can increase the possibility of a server failure, it is best to avoid it on production databases.
