Re: How do I initialize the root dbspace?

Bill Bertovich wrote: > However, I ran into a problem (running out of space again) while loading up > a customer's database. So, I thought that now would be a good time to > clean up some of the crap. So here is what I did. > > 1) I exported the databases (2) we needed to save and dropped them. > 2) I dropped the db space for these two databases and recreated it so it > had one chunk (87,500 pages). > 3) I left the root space alone. (currently 3 chunks 35,000 20,000 and > 10,000). > 4) It says there are only 59,000 pages free in the root space( out of > 125,000). > 5) The only loaded database is sysmaster. Why is sysmaster taking up so > much space when there are no other databases? > 6) I tried to re-initialize the database space ( oninit -i) and I got an > error: > oninit: Not enough room in ROOT DBspace. > oninit: Fatal error in shared memory initialization > 7) I thought the purpose of oninit -i was to reclaim all the lost space. > Where am I going wrong? > 8) All I want to do is start from scratch with a clean healthy database > environment. Does anyone have any suggestions? It looks like there is not enough space for the number of logs that are in the ONCONFIG file. Have you increased the number of size of the logical logs in anticipation of the new engine? Note that when you initialize the root dbspace the chunk table is wiped out so the rootdb space is now only the initial chunk named in the ONCONFIG file. All of your logical and physical log pages MUST fit in this one chunk at the time that oninit -i is run. Reduce the number of logs to 5 (the minimum) and make sure that the 5 logical logs and the physical log will fit in the first rootdb chunk, sysmaster only takes up about 1000 pages or less. Once you have initialized successfully you can add chunks to the rootdbs or create a separate dbspace for logsonly and then add new logs to the new dbspace with onparams and (after 5 times doing oninit -l and an oninit -c) drop the old ones. You can also move the physical log to thenew dbspace by bringing the engine down and editing the ONCONFIG file. In this way the rootdbs can be small (we have 150GB databases with a root dbspace with only 1200 pages used). I would recommend this approach, as well as separate dbspaces for the two databases. Just keep the root dbspace to the smallest chunk and use the two additional chunks to build a logspace dbspace. This will improve performance because rootdbs is hit heavily to locate objects and so are the logical and physical logs. Keeping these separate, on different disks, can make a big difference. Art S. Kagel