Hi there,
If I have an application that loads 5 grids at the same
time, does this means that it uses 5 connections?
After the grid is loaded, can I assume that the 5
connections are released and that the governor count goes
back to 0?
Thanks,
FP
hi FP,
FP wrote:
> Hi there,
> If I have an application that loads 5 grids at the same
> time, does this means that it uses 5 connections?
usually you use 1 connection for more operations, that's to say the very
same connection can serve your 5 "SELECT..." commands... so you only have 1
active connection with 5 non concurrent workloads... (the workloads number
is important and not the connection number)..
> After the grid is loaded, can I assume that the 5
> connections are released and that the governor count goes
> back to 0?
as reported, when each workload is executed it will decrement it's count,
and assuming you have 5 successive workloads, the batches count always is to
1-0 -1-0 -1-0 -1-0 -1-0... even if Ado.Net opens 2 connections, assuming no
other batches are executing...
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.10.0 - DbaMgr ver 0.56.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
sql
Showing posts with label loaded. Show all posts
Showing posts with label loaded. Show all posts
Wednesday, March 21, 2012
Friday, March 9, 2012
Good or Bad Idea? Multiple Tables for Data Import
Hello all,
We have an application which runs on a campaign basis. Data is loaded
throughout the day into our application. We typically load 20K - 30K rows
of data per campaign per day (total of about 150K - 200K row of data per
day).
We typically run about 30 - 35 campaigns simultaneously.
In order to increase the performance of our application, I was thinking of
loading each campaign into it's own table. The campaign tables would all be
identical. This would allow us to index each of these tables before each
campaign run to ensure the best possible performance.
What do you guys think?
We're finding that our application is being bogged down - we need to query
the tables continously as the application run... and return record sets
with minimal time.
Thanks.
--
Lucas Tam (REMOVEnntp@.rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
Newmarket Volvo Sucks! http://newmarketvolvo.tripod.comLucas
Have you read "Partitioned View" article in the BOL? If I understood you
correctly , that what you need .
"Lucas Tam" <REMOVEnntp@.rogers.com> wrote in message
news:Xns96D12EDD5C9ECnntprogerscom@.127.0.0.1...
> Hello all,
> We have an application which runs on a campaign basis. Data is loaded
> throughout the day into our application. We typically load 20K - 30K rows
> of data per campaign per day (total of about 150K - 200K row of data per
> day).
> We typically run about 30 - 35 campaigns simultaneously.
> In order to increase the performance of our application, I was thinking of
> loading each campaign into it's own table. The campaign tables would all
> be
> identical. This would allow us to index each of these tables before each
> campaign run to ensure the best possible performance.
> What do you guys think?
> We're finding that our application is being bogged down - we need to query
> the tables continously as the application run... and return record sets
> with minimal time.
> Thanks.
> --
> Lucas Tam (REMOVEnntp@.rogers.com)
> Please delete "REMOVE" from the e-mail address when replying.
> Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com|||"Uri Dimant" <urid@.iscar.co.il> wrote in
news:#O9$T2QuFHA.2076@.TK2MSFTNGP14.phx.gbl:
> Lucas
> Have you read "Partitioned View" article in the BOL? If I understood
> you correctly , that what you need .
Thanks URI, that seems to be what we need.
From your experience, would we gain a lot of performance by segmenting data
into it's own table?
Lucas Tam (REMOVEnntp@.rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com|||Hi
Yes, if you have appropriate indexes defined on the table you will be
benefit from performance.
"Lucas Tam" <REMOVEnntp@.rogers.com> wrote in message
news:Xns96D180999FD22nntprogerscom@.127.0.0.1...
> "Uri Dimant" <urid@.iscar.co.il> wrote in
> news:#O9$T2QuFHA.2076@.TK2MSFTNGP14.phx.gbl:
>> Lucas
>> Have you read "Partitioned View" article in the BOL? If I understood
>> you correctly , that what you need .
>
> Thanks URI, that seems to be what we need.
> From your experience, would we gain a lot of performance by segmenting
> data
> into it's own table?
>
> --
> Lucas Tam (REMOVEnntp@.rogers.com)
> Please delete "REMOVE" from the e-mail address when replying.
> Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com
We have an application which runs on a campaign basis. Data is loaded
throughout the day into our application. We typically load 20K - 30K rows
of data per campaign per day (total of about 150K - 200K row of data per
day).
We typically run about 30 - 35 campaigns simultaneously.
In order to increase the performance of our application, I was thinking of
loading each campaign into it's own table. The campaign tables would all be
identical. This would allow us to index each of these tables before each
campaign run to ensure the best possible performance.
What do you guys think?
We're finding that our application is being bogged down - we need to query
the tables continously as the application run... and return record sets
with minimal time.
Thanks.
--
Lucas Tam (REMOVEnntp@.rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
Newmarket Volvo Sucks! http://newmarketvolvo.tripod.comLucas
Have you read "Partitioned View" article in the BOL? If I understood you
correctly , that what you need .
"Lucas Tam" <REMOVEnntp@.rogers.com> wrote in message
news:Xns96D12EDD5C9ECnntprogerscom@.127.0.0.1...
> Hello all,
> We have an application which runs on a campaign basis. Data is loaded
> throughout the day into our application. We typically load 20K - 30K rows
> of data per campaign per day (total of about 150K - 200K row of data per
> day).
> We typically run about 30 - 35 campaigns simultaneously.
> In order to increase the performance of our application, I was thinking of
> loading each campaign into it's own table. The campaign tables would all
> be
> identical. This would allow us to index each of these tables before each
> campaign run to ensure the best possible performance.
> What do you guys think?
> We're finding that our application is being bogged down - we need to query
> the tables continously as the application run... and return record sets
> with minimal time.
> Thanks.
> --
> Lucas Tam (REMOVEnntp@.rogers.com)
> Please delete "REMOVE" from the e-mail address when replying.
> Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com|||"Uri Dimant" <urid@.iscar.co.il> wrote in
news:#O9$T2QuFHA.2076@.TK2MSFTNGP14.phx.gbl:
> Lucas
> Have you read "Partitioned View" article in the BOL? If I understood
> you correctly , that what you need .
Thanks URI, that seems to be what we need.
From your experience, would we gain a lot of performance by segmenting data
into it's own table?
Lucas Tam (REMOVEnntp@.rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com|||Hi
Yes, if you have appropriate indexes defined on the table you will be
benefit from performance.
"Lucas Tam" <REMOVEnntp@.rogers.com> wrote in message
news:Xns96D180999FD22nntprogerscom@.127.0.0.1...
> "Uri Dimant" <urid@.iscar.co.il> wrote in
> news:#O9$T2QuFHA.2076@.TK2MSFTNGP14.phx.gbl:
>> Lucas
>> Have you read "Partitioned View" article in the BOL? If I understood
>> you correctly , that what you need .
>
> Thanks URI, that seems to be what we need.
> From your experience, would we gain a lot of performance by segmenting
> data
> into it's own table?
>
> --
> Lucas Tam (REMOVEnntp@.rogers.com)
> Please delete "REMOVE" from the e-mail address when replying.
> Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com
Subscribe to:
Posts (Atom)