Limiting traces in Profiler

I've opened a trace in Profile, and now want to limit the results based on
the TextData field. I've setup a filter for "textdata not like exec
some_existing_sp" and that worked fine.
How is a "or" added here, if possible?
I'd like a filter something like "textdata not like (exec some_existing_sp)
or (exec some_existing_sp2)".
Or and "()" don't seem to work though.
Marco
Close and expand the 'NOT LIKE' and you should get another input box.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"Marco Shaw" <marco@.Znbnet.nb.ca> wrote in message
news:uQLNEDl4GHA.1248@.TK2MSFTNGP03.phx.gbl...
> I've opened a trace in Profile, and now want to limit the results based on
> the TextData field. I've setup a filter for "textdata not like exec
> some_existing_sp" and that worked fine.
> How is a "or" added here, if possible?
> I'd like a filter something like "textdata not like (exec
> some_existing_sp)
> or (exec some_existing_sp2)".
> Or and "()" don't seem to work though.
> Marco
>

Limitations of SQL Server 2000?

Hello, we are running SQL 2000 Enterprise on a quad 2.8Ghz proc server
running 2003 Enterprise. Plenty of ram and hard drive space. I've also
just got access to a 8 CPU server which we've just begun using as well.
Now I'm hearing word from my management that we will be moving towards
Oracle because of a limitation with SQL Server 2000. All because an
individual sites SQL server cannot deal with more than 25 million rows.
I personally have tables with over 150 million records, but I haven't
tried to dump 25 million into
I have no idea where this comes from, and I doubt there is any
supporting evidence. I'm not opposed to Oracle, just wondering why we
are trying to fix what isn't broken.
Can anybody point me towards what this limitation, or describe a
similar scenario?
Check out "Maximum Capacity Specifications" in the BOL. Your management is
wrong. SQL Server has handled databases over 10.5 TB in size. Most
problems I've seen with SQL Server (since 1993) have been
application-related.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
<MICHAEL_SUNLIN@.COUNTRYWIDE.COM> wrote in message
news:1127156075.664445.58460@.o13g2000cwo.googlegro ups.com...
Hello, we are running SQL 2000 Enterprise on a quad 2.8Ghz proc server
running 2003 Enterprise. Plenty of ram and hard drive space. I've also
just got access to a 8 CPU server which we've just begun using as well.
Now I'm hearing word from my management that we will be moving towards
Oracle because of a limitation with SQL Server 2000. All because an
individual sites SQL server cannot deal with more than 25 million rows.
I personally have tables with over 150 million records, but I haven't
tried to dump 25 million into
I have no idea where this comes from, and I doubt there is any
supporting evidence. I'm not opposed to Oracle, just wondering why we
are trying to fix what isn't broken.
Can anybody point me towards what this limitation, or describe a
similar scenario?
|||On 19 Sep 2005 11:54:35 -0700, MICHAEL_SUNLIN@.COUNTRYWIDE.COM wrote:
>Can anybody point me towards what this limitation, or describe a
>similar scenario?
No, but half the developers in Los Angeles have worked at Countrywide
at some time in the last ten years, and are aware of this Oracle
project. It was begun when the mortgage boom was at its peak about
three years ago and all their current SQLServer systems hit capacity.
In a fit of pique, panic, and good salesmanship from Oracle, a new
project was born, has gone through about three names at last count,
and is now 300% over budget and schedule. Need one say more? Just
that, with new hardware and some extended tuning, they're still
happily running on SQLServer.
J.
|||In the same vein, I usually tell people that if they have perf problems with
SQL Server, they can migrate to Oracle and if they have perf problems with
Oracle, they can migrate to SQL Server. How so? Because they'll have to
clean up their code in order to do the migration. It isn't the migration
that pays the dividend, it's the code/design cleanup that does. It's much
cheaper than the migration.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
"JXStern" <JXSternChangeX2R@.gte.net> wrote in message
news:brvui11h9g0fbtpctk0540mlicbc5jg3io@.4ax.com...
On 19 Sep 2005 11:54:35 -0700, MICHAEL_SUNLIN@.COUNTRYWIDE.COM wrote:
>Can anybody point me towards what this limitation, or describe a
>similar scenario?
No, but half the developers in Los Angeles have worked at Countrywide
at some time in the last ten years, and are aware of this Oracle
project. It was begun when the mortgage boom was at its peak about
three years ago and all their current SQLServer systems hit capacity.
In a fit of pique, panic, and good salesmanship from Oracle, a new
project was born, has gone through about three names at last count,
and is now 300% over budget and schedule. Need one say more? Just
that, with new hardware and some extended tuning, they're still
happily running on SQLServer.
J.
|||On Tue, 20 Sep 2005 07:38:45 -0400, "Tom Moreau"
<tom@.dont.spam.me.cips.ca> wrote:
>In the same vein, I usually tell people that if they have perf problems with
>SQL Server, they can migrate to Oracle and if they have perf problems with
>Oracle, they can migrate to SQL Server. How so? Because they'll have to
>clean up their code in order to do the migration. It isn't the migration
>that pays the dividend, it's the code/design cleanup that does. It's much
>cheaper than the migration.
Prezactly.
In this case, there was (and I assume still is) also an extremely
ambitious plan to merge and rationalize a bunch of related databases
into a single company-wide schema, or meta-schema, or ontology, or
phylogeny, or taxonomy, or whatever it is everyone has always thought
they were doing on such projects. It's like Captain Queeg proving the
mess boys took the strawberries, I think, an obsession that takes hold
and distracts from any real progress.
Anybody ever see one of these project succeed? I haven't, but I
suspect that some, maybe 10%, actually get deployed, at least.
Whether *any* show a positive ROI, I really wonder.
J.
|||My guess is that an Oracle bigot made it into upper management and simply
decreed that it must be so. Forget about justifying it. Eventually, when
they realize they spent a ton of money and got nothing back, they'll can the
jerk and look at improving their code. Yeah, and maybe I'll win the
lottery. ;-)
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
"jxstern" <jxstern@.nowhere.xyz> wrote in message
news:6km0j1hpfndba26oj7adrgaene8f6c688b@.4ax.com...
On Tue, 20 Sep 2005 07:38:45 -0400, "Tom Moreau"
<tom@.dont.spam.me.cips.ca> wrote:
>In the same vein, I usually tell people that if they have perf problems
>with
>SQL Server, they can migrate to Oracle and if they have perf problems with
>Oracle, they can migrate to SQL Server. How so? Because they'll have to
>clean up their code in order to do the migration. It isn't the migration
>that pays the dividend, it's the code/design cleanup that does. It's much
>cheaper than the migration.
Prezactly.
In this case, there was (and I assume still is) also an extremely
ambitious plan to merge and rationalize a bunch of related databases
into a single company-wide schema, or meta-schema, or ontology, or
phylogeny, or taxonomy, or whatever it is everyone has always thought
they were doing on such projects. It's like Captain Queeg proving the
mess boys took the strawberries, I think, an obsession that takes hold
and distracts from any real progress.
Anybody ever see one of these project succeed? I haven't, but I
suspect that some, maybe 10%, actually get deployed, at least.
Whether *any* show a positive ROI, I really wonder.
J.

Limit server resources per query

Hello,
I've got a huge query that takes a fair amount of time to
run, and ideally this query will be run in the middle of
the night, so I wont have any issues with any customer
facing applications...
However in testing, I need to develop this report in the
daytime, and dont have the liberty of having a development
server. I was curious if in a sql statement, I could
specify that I'd rather have a query take longer, than
prevent other applications from being able to process data
in a timely fashion. (I get timeouts etc in the other apps)
As it sits this query takes about 4 minutes on a quite
fast sql server, and I dont mind it so much, but it seems
in that 4 minutes, other services are really hurting.
Thanks in advance,
Weston Weems
There is no option such as the one you describe but you can add MAXDOP hints
to the sql statements that will limit the number of processors used by the
query. So if you have 4 procs you can set it to 2 and leave 2 for the other
users. It may take longer but should be more respectful of the other users.
Andrew J. Kelly SQL MVP
"Weston Weems" <anonymous@.discussions.microsoft.com> wrote in message
news:0ae401c51848$8b06fc90$a501280a@.phx.gbl...
> Hello,
> I've got a huge query that takes a fair amount of time to
> run, and ideally this query will be run in the middle of
> the night, so I wont have any issues with any customer
> facing applications...
> However in testing, I need to develop this report in the
> daytime, and dont have the liberty of having a development
> server. I was curious if in a sql statement, I could
> specify that I'd rather have a query take longer, than
> prevent other applications from being able to process data
> in a timely fashion. (I get timeouts etc in the other apps)
> As it sits this query takes about 4 minutes on a quite
> fast sql server, and I dont mind it so much, but it seems
> in that 4 minutes, other services are really hurting.
> Thanks in advance,
> Weston Weems