ph_alerts table
Frank (IDS 12.10.FC4 on Linux) found the sysadmin database's ph_alerts table growing in rootdbs and occasionally threatening to fill the 2 GB space, and asked whether to enlarge rootdbs or move the table. Respondents recommended relocating the whole sysadmin database with admin()/task('reset sysadmin','<dbspace>'), checking the online log for "'sysadmin' database built successfully"; no downtime is needed, but the reset drops and rebuilds sysadmin, wiping ph_run, ph_alert, results and command_history data plus any custom tasks/sensors/thresholds. They also advised verifying that the built-in Job Results Cleanup and Alert Cleanup tasks are enabled, since disabling them lets the tables grow huge.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi, Folks, IDS12.10 FC4, Linux 6 The ph_alerts table resides at root db spaces by default. The problem is , It sometimes can threaten to use all of the space of rootdbs (happened couple of times). Thinking about some options to mitigate, ---Increase the size of our rootdbs ( currently 2 GB) ---Move it out of rootdbs ( steps to do it ? feeling sort of uncomfortable ...) ..... Any comments? Thanks Frank --001a1146ed3af77cc405196d34ff
There is a task to move the sysadmin database to another dbspace. Now why isn't there a task to move any database ..... Cheers Paul > Hi, Folks, > > IDS12.10 FC4, Linux 6 > > The ph_alerts table resides at root db spaces by default. > The problem is , It sometimes can threaten to use all of the space of > rootdbs (happened couple of times). > > Thinking about some options to mitigate, > > ---Increase the size of our rootdbs ( currently 2 GB) > > ---Move it out of rootdbs ( steps to do it ? feeling sort of > uncomfortable ...) > > ...... > Any comments? > > Thanks > Frank > > --001a1146ed3af77cc405196d34ff > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > -- Paul Watson Tel: +1 913-674-0360 Mob: +1 913-387-7529 Web: www.oninit.com Oninit® is a registered trademark of Oninit LLC Failure is not as frightening as regret. If you want to improve, be content to be thought foolish and stupid. What this country needs are more unemployed politicians
Hi Frank, To move the sysadmin into another dbspace use the admin() or task() function with the first argument reset sysadmin and the second the name of the dbspace. If no second argument is used it will rebuild it on the root dbspace. When moving the sysadmin it has to be checked on the online log if it is already rebuild by looking for the string 'sysadmin' database built successfully.. Bear in mind that moving the sysadmin will in fact destroy and recreate it, meaning that only the built-in tasks, sensors and thresholds are kept, new ones are wiped along data on the ph_run, ph_alert and result tables and the command_history table. Keen regards. On Fri, 26 Jun 2015 at 16:16 FRANK <yunyaoqu@gmail.com> wrote: > Hi, Folks, > > IDS12.10 FC4, Linux 6 > > The ph_alerts table resides at root db spaces by default. > The problem is , It sometimes can threaten to use all of the space of > rootdbs (happened couple of times). > > Thinking about some options to mitigate, > > ---Increase the size of our rootdbs ( currently 2 GB) > > ---Move it out of rootdbs ( steps to do it ? feeling sort of > uncomfortable ...) > > ...... > Any comments? > > Thanks > Frank > > --001a1146ed3af77cc405196d34ff > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --047d7b450b1086560a05196d6817
Thanks Ricardo and Paul! Seems Moving sysadmin database incur downtime. At this moment, I am thinking to crease the size of root dbs( add chunk). But I can not recall, if too big rootdbs could give negative impact or not. Thanks Frank On Fri, Jun 26, 2015 at 11:29 AM, Ricardo Henriques < ricardoaireshenriques@gmail.com> wrote: > Hi Frank, > > To move the sysadmin into another dbspace use the admin() or task() > function with the first argument reset sysadmin and the second the name > of the dbspace. > > If no second argument is used it will rebuild it on the root dbspace. > > When moving the sysadmin it has to be checked on the online log if it is > already rebuild by looking for the string 'sysadmin' database built > successfully.. > > Bear in mind that moving the sysadmin will in fact destroy and recreate it, > meaning that only the built-in tasks, sensors and thresholds are kept, new > ones are wiped along data on the ph_run, ph_alert and result tables and the > command_history table. > > Keen regards. > > On Fri, 26 Jun 2015 at 16:16 FRANK <yunyaoqu@gmail.com> wrote: > > > Hi, Folks, > > > > IDS12.10 FC4, Linux 6 > > > > The ph_alerts table resides at root db spaces by default. > > The problem is , It sometimes can threaten to use all of the space of > > rootdbs (happened couple of times). > > > > Thinking about some options to mitigate, > > > > ---Increase the size of our rootdbs ( currently 2 GB) > > > > ---Move it out of rootdbs ( steps to do it ? feeling sort of > > uncomfortable ...) > > > > ...... > > Any comments? > > > > Thanks > > Frank > > > > --001a1146ed3af77cc405196d34ff > > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --047d7b450b1086560a05196d6817 > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a113a984247536305196db033
No down time necessary in moving the sysadmin database. You have a 2 GB root dbspace, I don't know how much you want to add but it does not seem relevant. But if you are worried about performance, then you have one more motive to move away the sysadmin into another dbspace. Best On Fri, 26 Jun 2015 at 16:50 FRANK <yunyaoqu@gmail.com> wrote: > Thanks Ricardo and Paul! > > Seems Moving sysadmin database incur downtime. > > At this moment, I am thinking to crease the size of root dbs( add > chunk). > But I can not recall, if too big rootdbs could give negative impact or > not. > > Thanks > Frank > > On Fri, Jun 26, 2015 at 11:29 AM, Ricardo Henriques < > ricardoaireshenriques@gmail.com> wrote: > > > Hi Frank, > > > > To move the sysadmin into another dbspace use the admin() or task() > > function with the first argument reset sysadmin and the second the name > > of the dbspace. > > > > If no second argument is used it will rebuild it on the root dbspace. > > > > When moving the sysadmin it has to be checked on the online log if it is > > already rebuild by looking for the string 'sysadmin' database built > > successfully.. > > > > Bear in mind that moving the sysadmin will in fact destroy and recreate > it, > > meaning that only the built-in tasks, sensors and thresholds are kept, > new > > ones are wiped along data on the ph_run, ph_alert and result tables and > the > > command_history table. > > > > Keen regards. > > > > On Fri, 26 Jun 2015 at 16:16 FRANK <yunyaoqu@gmail.com> wrote: > > > > > Hi, Folks, > > > > > > IDS12.10 FC4, Linux 6 > > > > > > The ph_alerts table resides at root db spaces by default. > > > The problem is , It sometimes can threaten to use all of the space of > > > rootdbs (happened couple of times). > > > > > > Thinking about some options to mitigate, > > > > > > ---Increase the size of our rootdbs ( currently 2 GB) > > > > > > ---Move it out of rootdbs ( steps to do it ? feeling sort of > > > uncomfortable ...) > > > > > > ...... > > > Any comments? > > > > > > Thanks > > > Frank > > > > > > --001a1146ed3af77cc405196d34ff > > > > > > > > > > > > > > > > > > ******************************************************************************* > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > --047d7b450b1086560a05196d6817 > > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --001a113a984247536305196db033 > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e011771a9dbb2f905196dcd41
I have never moved it on a very busy system but I don't see why you need downtime. Cheers Paul > Thanks Ricardo and Paul! > > Seems Moving sysadmin database incur downtime. > > At this moment, I am thinking to crease the size of root dbs( add > chunk). > But I can not recall, if too big rootdbs could give negative impact or > not. > > Thanks > Frank > > On Fri, Jun 26, 2015 at 11:29 AM, Ricardo Henriques < > ricardoaireshenriques@gmail.com> wrote: > >> Hi Frank, >> >> To move the sysadmin into another dbspace use the admin() or task() >> function with the first argument reset sysadmin and the second the name >> of the dbspace. >> >> If no second argument is used it will rebuild it on the root dbspace. >> >> When moving the sysadmin it has to be checked on the online log if it is >> already rebuild by looking for the string 'sysadmin' database built >> successfully.. >> >> Bear in mind that moving the sysadmin will in fact destroy and recreate >> it, >> meaning that only the built-in tasks, sensors and thresholds are kept, >> new >> ones are wiped along data on the ph_run, ph_alert and result tables and >> the >> command_history table. >> >> Keen regards. >> >> On Fri, 26 Jun 2015 at 16:16 FRANK <yunyaoqu@gmail.com> wrote: >> >> > Hi, Folks, >> > >> > IDS12.10 FC4, Linux 6 >> > >> > The ph_alerts table resides at root db spaces by default. >> > The problem is , It sometimes can threaten to use all of the space of >> > rootdbs (happened couple of times). >> > >> > Thinking about some options to mitigate, >> > >> > ---Increase the size of our rootdbs ( currently 2 GB) >> > >> > ---Move it out of rootdbs ( steps to do it ? feeling sort of >> > uncomfortable ...) >> > >> > ...... >> > Any comments? >> > >> > Thanks >> > Frank >> > >> > --001a1146ed3af77cc405196d34ff >> > >> > >> > >> > >> >> > ******************************************************************************* >> > Forum Note: Use "Reply" to post a response in the discussion forum. >> > >> > >> >> --047d7b450b1086560a05196d6817 >> >> >> >> > ******************************************************************************* >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> > > --001a113a984247536305196db033 > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > -- Paul Watson Tel: +1 913-674-0360 Mob: +1 913-387-7529 Web: www.oninit.com Oninit® is a registered trademark of Oninit LLC Failure is not as frightening as regret. If you want to improve, be content to be thought foolish and stupid. What this country needs are more unemployed politicians
I agree with Paul about no downtime required for moving the sysadmin database. DEFINITELY move it to another dbspace. I think it's a bit tricky but not that bad. I did that about 2 years ago at a site. I add chunks as needed. I've recently turned on sqltrace again, and one of the engines have 3M rows gathered since I turned off the cleanup task: Job Results Cleanup Off Remove all old job results entries from the system. Thanks- Mark Scranton The Mark Scranton Group mark@markscranton.com
Besides the Job Results Cleanup task, check the status of Alert Cleanup. By default I believe they are turn on and deletes rows as follow: Job Results Cleanup ph_bg_jobs_results WHERE ph_bgr_starttime > 30 DAYS Alert Cleanup ph_run and ph_alert WHERE alert_time > 15 DAYS On Fri, 26 Jun 2015 at 17:32 MARK SCRANTON <mark@markscranton.com> wrote: > I agree with Paul about no downtime required for moving the sysadmin > database. > DEFINITELY move it to another dbspace. I think it's a bit tricky but not > that > bad. I did that about 2 years ago at a site. I add chunks as needed. I've > recently turned on sqltrace again, and one of the engines have 3M rows > gathered since I turned off the cleanup task: > > Job Results Cleanup Off Remove all old job results entries from the system. > > Thanks- > Mark Scranton > The Mark Scranton Group > mark@markscranton.com > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --f46d043be06c41ef1b05196e7054