I wouldn't think that object relationships would have an issue on server start-up (other than the first time it is built). I was under the impression that this is something that is loaded and referenced on demand by Developer Studio. While it certainly does affect the size of your database, I wouldn't think that the BMC developers would load the relationships into the remedy server process memory (on startup) in the event that someone might need it in the future when they run Developer Studio and invoke Object Relationships. This would be incredibly inefficient. Just saying. Terry
_____ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller Sent: February-19-14 6:44 PM To: arslist@ARSLIST.ORG Subject: Re: Why does the ARS Service take so long to start? ** We do not notice a difference between production with or without object relationships turned on either. For the upgrade last weekend we turned off relationships so all of the upgrade def imports would not be impacted by the need to record the changes. The start time was about 2 1/2 minutes with relationships off and with them on (of course after that first time when they were built after the upgrade). We didn't have them on in production until the last year or so. Haven't noticed any issues. Jason On Wed, Feb 19, 2014 at 2:23 PM, LJ LongWing <lj.longw...@gmail.com> wrote: ** No, the Delta is NOT built on future reboots, the Delta is managed during code changes 'real time'. I have enabled this on all of my production servers since it became a feature, and I don't experience issues, other than a slowdown during code changes while it updates the references :) On Wed, Feb 19, 2014 at 2:34 PM, Joe D'Souza <jdso...@shyle.net> wrote: ** I should have mentioned that this happens only on the first run after it is enabled. After which it only builds the delta. And as Rick pointed out, this need not be enabled on production servers. Joe _____ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Wednesday, February 19, 2014 4:22 PM To: arslist@ARSLIST.ORG Subject: Re: Why does the ARS Service take so long to start? ** Joe, I'm not entirely sure that your statement regarding Object Relationships during startup is correct. I can guarantee you that on startup, if you have the box checked, and the objects aren't built...it builds them, that is 100% true, but management of those records is done while the server is online, as relationships change, not during startup....so I'm not entirely sure having them turned on has any impact on startup times, beyond the time it takes to build the relationships on the initial startup. On Wed, Feb 19, 2014 at 2:11 PM, Joe D'Souza <jdso...@shyle.net> wrote: ** This one is true - it is because on Oracle, during the startup, the database is read in chunks (100 rows at a time if I recall right) which I believe is a Oracle client limitation. Another factor affecting startup time is if you have enabled object relationship. This is gathered during startup and could delay startup by several minutes. Joe _____ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Tauf Chowdhury Sent: Wednesday, February 19, 2014 11:15 AM To: arslist@ARSLIST.ORG Subject: Re: Why does the ARS Service take so long to start? I recall a while back someone explained that there is also a difference between SQL and Oracle DB where The ITSM env on Oracle takes longer to start than SQL Server Sent from my iPhone On Feb 19, 2014, at 10:18 AM, "Pierson, Shawn" <shawn.pier...@energytransfer.com> wrote: ** You bring up a good point. From what I've seen the CPU and RAM are never too high even when starting up, and the database connection should actually be a decent connection (both servers are on the same switch, which I can tell thanks to ADDM) but I'd think that probably is one of the limiting factors of startup. My suspicion is that BMC's increasing reliance on plugins, which seem to be black boxes that are hard to gain visibility into, is a major factor as well. It would be an interesting test to have two pieces of the same hardware with AR System installed, one with the full ITSM, another without ITSM (but for charity include the supporting AR System modules like Approval that normally aren't used in fully custom shops) but with an equal number of forms, groups, and users, and time the startup times of both. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Wednesday, February 19, 2014 8:15 AM To: arslist@ARSLIST.ORG Subject: Re: Why does the ARS Service take so long to start? ** Shawn, In later versions of Remedy, you have the options to utilize multiple threads during the startup. As Rick points out, the main thing that Remedy is doing is pulling metadata out of the DB and storing it in RAM. So, there is a direct correlation between how many forms/fields/etc that you have, and how quickly you can get them out of the DB and into memory that determines how quickly your Remedy starts. Do you have that dedicated Fiber channel between your DB and App server that Remedy recommends? :) On Wed, Feb 19, 2014 at 5:57 AM, Pierson, Shawn <shawn.pier...@energytransfer.com> wrote: ** Since I have nothing better to do (just kidding, I'm swamped) I wanted to see if anyone on the list had a good explanation for something that has been an issue across multiple versions of Remedy for years. Specifically, on Windows, why does it take so long for Remedy to start up, and is there anything that can be done to make it load faster without sacrificing performance or functionality? If someone has found a way to get it to start up in less than 30 seconds, you should be given a job by BMC. It's been a while since I've worked with Remedy on Unix but I don't recall it taking as long to start as it does on Windows. Thanks, Shawn Pierson Remedy Developer | Energy Transfer Private and confidential as detailed here <http://www.energytransfer.com/mail_disclaimer.aspx> . If you cannot access hyperlink, please e-mail sender. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ Private and confidential as detailed here <http://www.energytransfer.com/mail_disclaimer.aspx> . If you cannot access hyperlink, please e-mail sender. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
