Posted by othellomy on 03/30/07 12:11

On Mar 30, 5:57 pm, "Zamdrist" <zamdr...@gmail.com> wrote:
> On Mar 30, 4:54 am, othell...@yahoo.com wrote:
>
>
>
>
>
> > On Mar 30, 12:48 am, "Zamdrist" <zamdr...@gmail.com> wrote:
>
> > > I did end up archiving off most of the data from the tables in
> > > question and wrote a custom interface to that using ASP.Net. Works
> > > like a charm, no indexes whatsoever.
>
> > Does that mean who have no io problems if you use ASP.NET?
>
> > Archiving and subsequently
>
> > > deleting the data from the production tables, and rebuilding existing
> > > indexes had little to no effect on performance unfortunately.
> > > Again...up a river with no paddle, lol.
>
> > The indexes you have are useless. Therefore, rebuilding them will not
> > make any difference. You need to identify what columns (preferably
> > one, at most 2) you need your clustered indexes for. Hopefully the
> > system will use those indexes.
>
> I copied (and subsequently deleted) from production a large amount of
> the data to a different table and server, and wrote an interface to
> that data in ASP.Net so the users, if needed could look back on older
> infrequently used data. Accessing that data works great.
>
> I could build more intelligent indexes for the data in production,
> although I doubt the application would behave any differently (faster)
> as I've verified it uses no views or stored procedures...it only uses
> in-line text based queries...Select fields From table Where...and so
> on.
>
> I have no access to the application code to change this behavior
> unfortunately.- Hide quoted text -
>
> - Show quoted text -

You might consider creating a new clustered index on a column that is
frequently used to join with other tables. Copy paste your code to QA
and run a showplan with no exec, on and find out if it is doing a
table scan or index search.

[Back to original message]