Database Queries SLOW after change script

Brian Donahue

Hi Jason,

Glad you like the software. If you're suffering problems with query
input, more than likely it's an index that's to blame. Can you look and see
what changes SQL Compare is making to your indexes?

Thanks,

Brian Donahue
Red Gate Technical Support

"Jason T. Lodice" <JLodice@acssecurities.com> wrote in message
news:poHbnBo5DHA.1668@server53...
> I'm using SQLCompare v2.03. The product is excellent and completely
solves
> a major problem in our shop.
>
> I have found though, that after generating a change script and running it
> against a target database, that certain queries become painfully
slow...even
> unable to finish.
>
> If I roll back the db to before the change script everything is ok, and if
I
> apply the individual T-SQL statements in the script without the
> Transactional Plumbing, it again works OK. Is this a known issue? I
> searched the FAQ and newsgroup and could find no one with a similar
problem.
>
> Any ideas? I'm trying to get approval to upgrade to the next version, and
> purchase the ToolKit for some custom tools, however, I can't convince the
> right people if we can't even get this version to work right.
>
> Thanks much!
>
>

Brian Donahue

Hi Jason,

The thing that comes to mind is to make sure that if you had a clustered
index before, to make sure it's re-created as a clustered index again when
SQL Compare scripts them. Depending on how you use your data, clustering can
help or hinder greatly on databases with lots of transactions going on.

Brian

"Jason T. Lodice" <JLodice@acssecurities.com> wrote in message
news:NR8v5Aq5DHA.1552@server53...
> What do you mean by changes? I see that any tables that needed to be
> updated are dropped, and recreated and the indexes are recreated, but as
far
> as I can tell, the new indexes are not any different than the previous
> indexes. Can you tell me what I should specifically look for?
>
> Also, I'm not even sure if the queries are just slower...in fact we have
not
> let them run to completion. For instance, one query would complete in 1
> second in query analyzer, and we let it run for 15:00 and then finally
> killed it.
>
> Thanks Brian!
>
> "Brian Donahue (Red Gate)" <brian.donahue@red-gate.com> wrote in message
> news:7tjrsJo5DHA.1844@server53...
> > Hi Jason,
> >
> > Glad you like the software. If you're suffering problems with query
> > input, more than likely it's an index that's to blame. Can you look and
> see
> > what changes SQL Compare is making to your indexes?
> >
> > Thanks,
> >
> > Brian Donahue
> > Red Gate Technical Support
> >
> > "Jason T. Lodice" <JLodice@acssecurities.com> wrote in message
> > news:poHbnBo5DHA.1668@server53...
> > > I'm using SQLCompare v2.03. The product is excellent and completely
> > solves
> > > a major problem in our shop.
> > >
> > > I have found though, that after generating a change script and running
> it
> > > against a target database, that certain queries become painfully
> > slow...even
> > > unable to finish.
> > >
> > > If I roll back the db to before the change script everything is ok,
and
> if
> > I
> > > apply the individual T-SQL statements in the script without the
> > > Transactional Plumbing, it again works OK. Is this a known issue? I
> > > searched the FAQ and newsgroup and could find no one with a similar
> > problem.
> > >
> > > Any ideas? I'm trying to get approval to upgrade to the next version,
> and
> > > purchase the ToolKit for some custom tools, however, I can't convince
> the
> > > right people if we can't even get this version to work right.
> > >
> > > Thanks much!
> > >
> > >
> >
> >
>
>