Here are a few suggestions:
- Build better indexes
- Archive old data in the subject table to reduce overall table size
- Use fewer LIKE statements...i.e., reduce ANYWHERE pattern matching in
fields where it's not necessary. LIKE is a performance killer
- Consider implementing the NOLOCK option
You can replicate the database on another server and use that strictly
for reporting. Your data will be behind, by how much depends on how you
replicate. Even if you do need up to the minute reports, you can at
least off load the user who don't need that.
Ben Cantatore
Remedy Manager
(914) 457-
Are any of the bind variable referring to a user?
a.g.bryan.14
On 7/17/09, manoj jain wrote:
>
> ** Hi Remedians,
>
> I need some suggesstions from your side related to performance issue.
> Our DBA team got one query due to this query performance issue occuring.
>
> *Query:*
> **
>
> *High I/O q
: Performnace Issue Due To Report Fetching
Are any of the bind variable referring to a user?
a.g.bryan.14
On 7/17/09, manoj jain wrote:
>
> ** Hi Remedians,
>
> I need some suggesstions from your side related to performance issue.
> Our DBA team got one query due to this query pe
Since you say that T28 is the Report form I would suggest doing the following.
Turn on SQL Logging on the server and capture the actual SQL statement being
sent to the database (What you have below is the cached version and debugging
is always easier when you see the actual query data instead o
5 matches
Mail list logo
