The ARS index internally creates DB Index. So, there won’t be difference from performance perspective, however, we recommend to create ARS Index to keep ARS & DB Index in sync.
To create Index, go to AR form ->property from Developer Studio.
When you index any field from remedy side it will automatically creates an index to the database as expalined byManish.But it is not recommended to create too less or too many indexes on the ARForm.Go through Performance Tunning pdf and you will get a better idea on the same.Let us know if you need some more info on the same.
This link may help
Your DBA will be the best person to tell you which field has to be indexed.
Also you can enable server side sql logs and run it through ARLogAnalyser to find out any long running query and you can probably identify the field to be indexed
below is the link
There are positives and negatives to indexing at the DB level.
The positive is that in some DBMS, the indexes can be moved to separate table spaces from the rest of the DB, which can increase performance. This is not possible with Remedy-managed indexes.
The negative is that once you allow the DB to control indexes, all changes to indexed fields you want to make in Remedy must also be made in the DB, or you will end up out of sync. This would be bad.
Configuring indexes at the Remedy level is done through the Developer Studio, on the properties of each Form. The exact path to those varies by version (7x vs 8x) of Developer Studio, so consult your documentation for details.
You CAN control where the indexes are created in a Remedy setup...but you must configure the proper db.cfg (I think that's the name) to put them in the separate tablespace/etc...I don't know the details because I have never done it...but I DO know that it's possible...
Few months backs We had faced a performance issue "issue was that CI search on HPD:Helpdesk form was taking too much time(around 5 minute),we decreased the CI search time by adding index at DB label,it increased the performance.
so from my past observation i would suggest you add it add Db lable, consulting with your DBA team would be best for you.
Why did you do it at the db instead of through Remedy?
I am agreed with LJ ,It is most recommended to create Indexes on DB side instead from AR Side.Please go through DB Ref pdf and search for Applying Indexes Section You will get an idea.
I'm sorry if I gave the wrong impression, but I suggest creating all indexes from WITHIN remedy...not directly at the DB level.
As LJ said, it's the other way around, you SHOULD create indexes through Remedy. Why? Simple. When you add an index to a form in dev environment and you want to export it to qualification / pre-production / production, you just have to export the form and import it, indexes come with the definition (.def).
Other reason? I worked on a project where DBA was gone and they actually went from 7.x to 7.6.03 and changed their database (Oracle to MS SQL Server).
A process that took 10 hours in Oracle was taking more than 24 with MS SQL Server, I spent a couple of days to tune that so it would only take like 4 hours.
After a while, customer saw that he had a mail from his DBA, years back, saying that he detected some slow SQL queries and he added some indexes... Some of them the same I detected.
So you see, definitely better to add those Remedy side.
So your indexes will "survive" your DBA's memory or he's fired or another project.
Another reason? Let's say your DBA creates a unique index (or composite) on a table.
Then you hire an external guy for a a job (interface, whatever) and he tries to add an index, remedy side, it'll fail because the index already exists but he can't see it Remedy side.
LJ, I've never even heard of anyone doing that. My experience has been that if a DBA were going to move the indexes, (s)he would want to control them all the way in the DB, and most don't want to take on the extra work at all.
I agree that apart from capacity issues for large-scale systems (which could be addressed in other ways), there isn't a strong value-add to taking control of the indexes in any way outside of Remedy.
I'm a bit confused....in the first paragraph you say that most dba's would want to have control of the index entirely, but in the second paragraph you said you would recommend keeping them in remedy....and I'm not entirely sure which response you are responding to ....just to consolidate my view
Remedy should control all indexes in a Remedy DB entirely. Any time a DBA takes control of the indexes at the db level it can cause issues when Remedy tries to do something with the form at a later time.
If for some reason there is a need, for performance reasons to put indexes in a different place on the hard drive than 'normal', Remedy provides methods to allow for that to happen while staying INSIDE the Remedy framework so that Remedy is familiar with everything happening in the DB.
OK, let me try again. 95% of DBAs are happy to leave the indexes alone, and let the Remedy Admins deal with them.
For the tiny minority who want or need to exact SOME control of the indexes, they generally want or need ALL control over them. Why? Because any split in the responsibility for the Remedy indexes brings with it complications in terms of coordinating updates, and those don't get significantly worse with full DBA control vs. partial. And if you consider that the personality type of the DBAs who want the control is to take full control of their DBs, we end up with a situation where the scenario you described is very unlikely to happen in real life, however technically possible it might well be.
If I am a Remedy admin asking for the indexes to be stored separately, I would think that the DBA team's taking over full control of the indexes to be a potential and possibly reasonable response. That way, only ONE team is responsible if something goes sideways with them, which avoids some finger-pointing. I also would not make such a request of ANY DBA unless I was sure that they clearly understood how Remedy interacts with the DB.