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 <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_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
