Re: Table modification transaction size problem
Posted in 1995
Rob seems to think I was making a sales pitch. That is not the case. I was merely trying to avoid posting a very long explanation which I would have made available on a one-to-one basis to the individual concerned. I also note that Rob's answer merely avoids the problem and doesn't answer the question asked. For everybody's information the section of the training course dealing with this topic is some 4 pages long and would not transfer to mail very easily. But - if anybody wants to book me for a course I'm always willing to consider offers. > onlinedbc@cix.compulink.co.uk ("Malcolm Weallans") wrote: > > >I show people how to do this on my OnLine Administration courses. > >Interested? > > >> Hello, > >> > I have a esql-c program that is going to alter a table. > >> > This is Online database with transactions > >> > I need to calculate if this alter will hang due to the size > of > the >transaction being to big. > >> > I would assume I need to calucate how big the transaction > would > be >and then calulate how big of a transaction my online > system can > handle.>> > Has anyone ever done this??? > >> > Any sugestions?? > >> > Thanks > >> > Randy Paries > >> rtparies@ingr.com > >> > > > > >Malcolm Weallans > >Online Database Consultancy > >Phone 0628-72154 > >Fax 0628-37463 > >CIX - onlinedbc > > This is a forum for FREE exchange of information. I appreciate you > trting tomake a living but this person has a valid question and does not > deserve a salespitch as an answer, > > The answer is: > > 1) Switch the database to NO LOGGING. (You can do this easily through > tbmonitoror from the command line). > > 2) Perform the ALTER statements, which, by the way, run faster because > there isless I/O writting logs to disks). > > 3) Take database off-line. > > 4) Temporariy change the Tape Backup device setting to "/dev/null" > (OPTIONAL) ( This makes the next mandatory step very fast ). > > 5) Perform a level 0 archive. > > 6) Restore the database back to it previous LOGGING Option (I think > Unbufferedis best). > > 7) Restore the Tape device back to proper setting, if step 4 was done. > > 8) Bring the database back on-line. > > > You may choose to do a real tape archive in step 5. All the better. > > > -------------------------------------------------------- > Rob McAllister rmcall@on-ramp.ior.com > Spokane, WA > "On all good programmers a little core must dump" > Malcolm Weallans Online Database Consultancy Phone 0628-72154 Fax 0628-37463 CIX - onlinedbc