Same here. We only use Record Object Relationships on non production servers. We too run ARInside against all of the servers.as well. We find we really only need to look at the relationships in Dev Studio when we are doing development work and if we really need to research relationships in production ARInside does the job.
Jason On Thu, May 26, 2011 at 10:46 AM, patchsk <[email protected]> wrote: > Exactly the first time you enable record object relationships it will > take more than an hour to startup, subsequent startups should be > normal time. > But once you turn it off, a restart will remove all the relationship > entries created. > We turned it on only on dev/qa server,we do not see much need to turn > it on production server. > More over we are using arinside which is working perfectly with > ars7.6.03. > It is a lot more useful/user friendly than devstudio object > relationships. > Only downside is you need to run arinside periodically to get latest > updates, where as devstudio object relationships get created on the > fly anytime new workflow is created/modified. > > On May 26, 12:26 pm, strauss <[email protected]> wrote: > > The 7.6.04 docs say that once you turn it on > (Record-Object-Relationships: T) it causes the server to record all > relationships before accepting any client connections, and that it may take > an hour or more to do so. I know it was doing something before I stopped > it... one CPU core (of 4) was at 50% utilization, but it is only making ONE > TCP/IP connection to the database; normally I have 68 TCP connections to the > SQL Server, so it isn't very efficient. Also the transaction log backup > after I had let it run for a while was over a gig in size - unusually large. > > > > What bothers me is that if you turn it on during the installs (file under > why the ITSM upgrade took 17 hours) it does not appear to be retained if a > subsequent installer turns it off. Then turning it back on again wipes your > server(s) out for an hour (server group members ALL must be either on, or > off). It's like the mid-tier caching that did not work properly, i.e. was > not really persistent, and restarting the mid-tier wiped it out and forced > another 30-minute fetching activity. In each case, if it is on a production > system your users WILL be impacted. > > > > Maybe Record-Object-Relationships: T is unsafe for use in anything but a > development environment. > > > > Christopher Strauss, Ph.D. > > Call Tracking Administration Manager > > University of North Texas Computing & IT Centerhttp://itsm.unt.edu/ > > > > > > > > > > > > > > > > -----Original Message----- > > From: Action Request System discussion list(ARSList) [mailto: > [email protected]] On Behalf Of strauss > > Sent: Thursday, May 26, 2011 11:16 AM > > To: [email protected] > > Subject: Re: ITSM - 7.6.4 Relating Objects > > > > I have had the same experience - if you turn it on after the fact (after > installing the apps) the server becomes irrevocably hung. I have made a > point of turning it on during installs and upgrades ( Set Object > Modification Log ON) but have yet to see any positive result from doing so, > possibly because other installers turn it back off again and leave it off > (SLM?). Then when you try to actually SEE relationships, it is not turned > on, and turning it on hangs your server delays startup by , and so on... > It's like the BPCU - it is supposed to work, but it doesn't, really. > > > > I had it turned on everywhere I could while installing my clean 7.6.04 > suite pre-production server - I had to keep turning it back on, and it is > still turned on there in Server Information, and if I open the HPD:Help Desk > form and select a field and right-click - Show Relationships it DOES display > relationships - usually an obscene number of them (60 for Priority*, 86 for > Service*+), so it can actually work. > > > > It keeps getting turned back off on my staging server, but I think it is > _supposed_ to be safe to turn it back on because it was on during the > installs/upgrades so the relationship information must have already been > generated and stored somewhere. Unfortunately, turning it on results in the > server startup being delayed for longer than I can tolerate - I get tired of > seeing more "Wait for server timed out" entries in the armonitor.log, so I > usually have to go back into the ar.cfg and change > Record-Object-Relationships: from T to F and try again. I just tried that, > and after twenty+ minutes of seeing it hung I rebooted the server. So no, I > can't say that it actually works, in the real world. > > > > Not having a fun day with BPCU 7.6.04.01000, so I am skeptical about the > chances of ANY BMC product released since 2008 working properly. > > > > Christopher Strauss, Ph.D. > > Call Tracking Administration Manager > > University of North Texas Computing & IT Centerhttp://itsm.unt.edu/ > > > > -----Original Message----- > > From: Action Request System discussion list(ARSList) [mailto: > [email protected]] On Behalf Of Sanford, Claire > > Sent: Thursday, May 26, 2011 10:19 AM > > To: [email protected] > > Subject: ITSM - 7.6.4 Relating Objects > > > > I have checked the BMC KB and found no answer. > > > > I went into Remedy to have it "relate the objects" the way the > documentation said to do it and now the DB is running wild. I can't even > log into Remedy to make it stop. A > > > > It appears to have stopped and started over. > > > > I tried to start the service manually using "arserver.exe -m" > > > > This is what is creating the huge logs. I have 2gb log files that have no > errors in them, but the application isn't letting me in. > > > > I rebooted the server and when it comes back up, I still get the ARERR90 > and can't connect. > > > > This is my "sandbox" server and we are not even in Test yet, so I am not > totally freaked out... Just minorly ;) > > > > Remedy ITSM 7.6.4 > > Oracle DB > > > > Claire Sanford > > Information Systems Division > > Memorial Hermann Healthcare System > > System Services Tower North - 2:105 > > 920 Frostwood, Houston, TX 77024 > > Phone: 713 338 6035 > > [email protected] > > > > > ___________________________________________________________________________ > ____ > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > > attend wwrug11www.wwrug.comARSList: "Where the Answers Are" > > > > > ___________________________________________________________________________ > ____ > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > > attend wwrug11www.wwrug.comARSList: "Where the Answers Are" > > > > > ___________________________________________________________________________ > ____ > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > > attend wwrug11www.wwrug.comARSList: "Where the Answers Are" > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
