Re: dropping temp db space problem

there are no sessions running, the engine has been restarted, nothing works! :( this sucks big time, I cann't afford to reinit and reload my data everytime this happens, how come a dbspace has to be empty in order to be dropped? especially a tempdb? thanks yan f_testa@yahoo.com wrote: > Run an oncheck to see what is in the temp dbspaces > (oncheck -pe > peoutput) and find out what sessions > are writing to them. Alert the sessions (users) to > suspend (exit) thier jobs to allow you to drop the > Temp dbspaces, recreate them, and possible restart > your engine. > > In article <77an6r$1l2$1@news.xmission.com>, > "Yan Zhu" <yan.zhu@infinity-insurance.com> wrote: > > > > hi all: > > I asked a question some days ago about temp db space not get cleaned > > up. The advice given were to drop it and recreate it. I used onmonitor > > trying to drop it, it says Cannot drop dbspace, ISAM error, dbspace is > > not empty. hmm, what do I do now? > > > > thanks. > > yan > > > > > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

Yan Zhu wrote: > there are no sessions running, the engine has been restarted, nothing works! > :( > > this sucks big time, I cann't afford to reinit and reload my data everytime > this happens, how come a dbspace has to > be empty in order to be dropped? especially a tempdb? If your temp dbspace is not empty after shutdown and normal restart, that sounds like a bug. Note that I am talking about a temp dbspace (one created with the -t option), not your DBSPACETEMP, which does not have to be a temp dbspace. Also, a normal restart drops temporary tblspaces, whereas some option of oninit (I forget which one) will skip this step. If oncheck -pe really says there is nothing in the dbspace, but you still can't drop it, then you should call Tech Support. As to why a dbspace has to be empty to be dropped, even a tempdb, how would you like it if you were using a table, and someone dropped the dbspace it was in? Not only wouldn't you be able to use your table anymore, but the system catalogs which track tables would now be corrupt, because they were not updated with the information that the table was yanked forcibly from the instance. In order to update the system catalogs, you must issue a DROP TABLE statement. June -- june_t@hotmail.com Grounded in Palo Alto, living on M&M's (plain)