Well, if you go on the BMC recommendations for DB and buffer cache settings you
will always be swapping queries in memory to disk …
A simple "%" bypasses all settings on an AR Server, so with that indexes are
useless and then you are relying on the table sizes …
I agree, interesting topic J
I see that the AST:AssetJoinASTPeople has a lot of this info. Thanks! I'll
try it!!
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Hennigan, Sandra, CTR, DSS
Sent: Wednesday, February 25, 2015 3:27 PM
To: arslist@ARSLIS
I'm sorry, meant to expand, that I also need things like AssetID, Serial
Number, Category, etc. Stuff from the Base Element Form.
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Hennigan, Sandra, CTR, DSS
Sent: Wednesday,
What about using AST:AssetPeople or AST:AssetJoinASTPeople?
Thank you,
Sandra
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Kemes, Lisa A DLA CTR INFORMATION
OPERATIONS
Sent: Wednesday, February 25, 2015 3:20 PM
To: a
There's no out of the box form that pulls all relationships to an asset into
one reportable form is there? Specifically Owned By, Used By and Supported By.
We are on 8.1 SP2. We have to create a custom form that collects all this
information in order to report on it.
Just wondering
Than
It's been a while since I checked but I think with most DBMS, a
clustered index is stored in memory / pages once it's used. So if this
is large then you can end up with a buffer thats gigs right?
Agreed that indexes are great on large tables but I don't think it's an
excuse not to keep the tab
"Adjust the indexing to match the most common queries"
And then there is the poor person(s) that has to run an uncommon query.
On Wed, Feb 25, 2015 at 11:17 AM, Brittain, Mark
wrote:
> **
>
> Its’ all about indexing. I have a large form on a 6.3 platform that
> contains over a million records a
Its' all about indexing. I have a large form on a 6.3 platform that contains
over a million records and just flies. Adjust the indexing to match the most
common queries. Company, Status, Assigned Group are probably the most common.
Anything that is required and menu driven would be good candidat
Your Tomcat is running on port 8080 and that is what responds when you
enter the second URL.
Browsing to your first URL will use the default port of 80. And that
will be the IIS that should respond.
So either IIS is down, or the ISAPI Tomcat connector in IIS is not
configured.
Regards
Danny
Absolutely agree. An RDBMS is meant for massive amounts of data "so long as
its efficiently stored and retrieved". That's the key factor.
Else its just like storing it in an Excel sheet if one does not pay heed to
queries and the way data is retrieved.
Cheers
Joe
_
From: Ac
John,
Isn't reading an index with fewer rows going to be quicker than reading
one with more rows?
Personally, I think no one task is a silver bullet to performance
tuning. I would implement archiving and monitor for table scans.
I welcome anything, a product or a HowTo that will improve an
Actually, we took a few more of the windows updates and all is well now for
this issues. Thanks for your help. Still having the port issue though. Can only
access the mid-tier via "http://mydnsname:8080/shared/login.jsp".
On Friday, February 20, 2015 10:58 AM, Rick Westbrock
wrote:
Hi we just did a P to V of our itsm 7.0.1 system. Server is up and running now
as a VM along with the Mid-tier. When I try to access the mid-tier via this
URL"http://mydnsname/shared/login.jsp"; I am met with this error: "The webpage
cannot be found". However, if I specify the port
"http://myd
13 matches
Mail list logo
