Re: User tool and Newer AR server

[William Rentfrow]

This looks like an instance of where the API call is updated in the newer 
version.  I've seen that kind of thing before.  Back when Remedy went from 5 to 
6 the nature of the GLWEF API call on a version 5.x WUT would crash a version 
6x server.

Something like 3 users got missed in the upgrade to their desktop app and 
whenever one of those users would invoke that API call by opening a form the 
whole thing would go down.

/Trying hard not to sound like an old codger  "Why back in my day we had use a 
rotary dial to make API calls."

William Rentfrow
wrentf...@stratacominc.com
Office: 715-204-3061 or 701-232-5697x25
Cell: 715-498-5056

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W
Sent: Tuesday, October 20, 2015 2:22 PM
To: arslist@ARSLIST.ORG
Subject: Re: User tool and Newer AR server

**
That is cause the Web log shows
  SELECT DISTINCT 'no C1',C536870923 FROM T98 WHERE (T98.C7 = 0) ORDER BY 
C536870923 ASC, 1 ASC
versus the User tool log showing
  SELECT  T98.C1,C536870923 FROM T98 WHERE (T98.C7 = 0) ORDER BY C536870923 
ASC, 1 ASC

The DISTINCT ‘no C1’ will only bring back from the database the 50 some records 
of the States (much more efficient than doing the distinct inside the AR Server 
process)

Fred

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Tuesday, October 20, 2015 1:47 PM
To: arslist@ARSLIST.ORG
Subject: Re: User tool and Newer AR server

**
hmmm...not sure how 20K is breaking downbut the interesting thing for me is 
that both the log for user and web both show 20k, but you say the web is 
working but user isn't

On Tue, Oct 20, 2015 at 11:54 AM, Grooms, Frederick W 
mailto:frederick.w.gro...@xo.com>> wrote:
**
1000

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ 
LongWing
Sent: Tuesday, October 20, 2015 11:31 AM
To: arslist@ARSLIST.ORG
Subject: Re: User tool and Newer AR server

**

I've seen that be the server side table chunk size too, what's that set to?

Sent with AquaMail for Android
http://www.aqua-mail.com
-Original Message-

On October 20, 2015 10:06:32 AM "Grooms, Frederick W"  wrote:
**
Actually my Max Entries Returned By GetList = 5000

I’m not sure where the 20k comes from as I did a grep on the server and 
couldn’t find any place where I have 20k


From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Tuesday, October 20, 2015 10:46 AM
To: arslist@ARSLIST.ORG
Subject: Re: User tool and Newer AR server

**
Fred,
Do you have your server properties set to return a maximum of 20K records?

-Original Message-
On Tue, Oct 20, 2015 at 9:00 AM, Grooms, Frederick W  wrote:
We just found another place where a newer AR Server breaks using the User Tool. 
 (Yes I know, we are trying to get users to move off of it)

AR Server   8.1.02 201408260235  (RedHat Linux)
AR User  7.6.04 SP4  Sep , 6 2012

We have a regular form to hold Zip codes.(42,000 + records)
There is a search menu against that form to list the State values (Label Field 
"State", Value Field "State", Sort on Label, Qualification: 'Status' = "Active")

When we were using the menu against a 7.6.04 server everything worked 
correctly.  Now that we have upgraded the server to 8.1.02 the User tool 
doesn't show the complete list anymore.

I went and captured SQL logs.
In User tool when opening a menu the selections are not complete.
 /* Mon Oct 19 2015 16:45:15.6810 */+API call
   /* Mon Oct 19 2015 
16:45:15.6803 */+EXPQRY ARExpandQueryMenu from Remedy User (protocol 18) at IP 
address 192.168.101.98  //
   /* Mon Oct 19 2015 
16:45:15.6805 */SELECT  * FROM ( SELECT  T98.C1,C536870923 FROM T98 WHERE 
(T98.C7 = 0) ORDER BY C536870923 ASC, 1 ASC ) WHERE ROWNUM <= 20001
   /* Mon Oct 19 2015 
16:45:15.7677 */OK
   /* Mon Oct 19 2015 
16:45:15.9169 */SELECT COUNT(*) FROM T98 WHERE (T98.C7 = 0)
   /* Mon Oct 19 2015 
16:45:15.9393 */OK
   /* Mon Oct 19 2015 
16:45:15.9584 */-EXPQRY   OK
 /* Mon Oct 19 2015 16:45:15.9620 */-API call

In Mid-Tier we get all the records.
 /* Mon Oct 19 2015 16:37:37.260 */+HTTP call

   /* Mon Oct 19 2015 16:37:37.2815 */+EXPQRY ARExpandQueryMenu from 
Mid-tier (protocol 20) at IP address 192.168.107.150  //
   /* Mon Oct 19 2015 16:37:37.2817 */SELECT  * FROM ( SELECT DISTINCT 'no 
C1',C536870923 FROM T98 WHERE (T98.C7 = 0) ORDER BY C536870923 ASC, 1 ASC ) 
WHERE ROWNUM <= 20001
   /* Mon Oct 19 2015 16:37:37.3187 */OK
   /* Mon Oct 19 2015 16:37:37.3202 */-EXPQRY   OK
 (ARNOTE 8914)

 /* Mon Oct 19 2015 16:37:37.277 */+MidTier 
ExpandMenu/20/ZIP:Valid_State_List//
 /* Mon Oct 19 2015 16:37:37.281 */+API call, Procedure #55
   /* Mon Oct 19 201

Re: Remedy 9.0 SQL requirements

[Rafael Rodriguez]

Ryan, take a look at the following link. I believe this will provide
information your looking for to make a decision.


Remedy 9.0 benchmark report has some data where we compared physical SQL
server to a VM. Essentially we saw similar performance and therefore using
a VM for a small or medium type of environment as a database server should
be okay. For production environment we recommend not to over-subscribe
resources and map (1-1 mapping) one VCPU to one physical core.


https://docs.bmc.com/docs/display/public/brid90/Mixed+workload+with+Microsoft+SQL+server+deployed+to+a+Virtual+Machine

On Tue, Oct 20, 2015 at 10:07 AM, Ryan Nicosia 
wrote:

> I've looked through the 9.0 upgrade documentation and outside of some
> basic sizing guidelines I'm not really finding what I'm looking for.
>
> I've also downloaded the worksheet that BMC put together for planning your
> resource requirements for 9.0 install based on users, ticket throughput,
> etc.
>
> What I am after are recommendations on a virtualized Microsoft SQL cluster
> and what we should provide to our SQL team on how SQL should be provisioned
> to support Remedy.  In the past, we ran into several issues with DB
> connectivity from ARS due to an unidentifiable issue with latency between
> the cluster (veritas in this instance) and the storage array where the
> database was actually housed.  The only solution was to revert back to a
> physical SQL server.
>
> We want to avoid this situation with our 9.0 upgrade by ensuring all of
> the SQL requirements are provided up front.  Unfortunately, it looks like
> BMC documentation is kind of lacking in this regard.
>
> So, for anybody that has upgraded to 9.0 and has a large user base and
> large DB with a lot of transactions, do you have any lessons learned or
> recommendations for Microsoft SQL server in a clustered environment?
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "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"