<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQL Server 2005
»
SQL Server 2005 Strategies
»
Keeping at table lean and highly available
22 posts, Page 1 of 3
1
2
3
»
»»
Keeping at table lean and highly available
Rate Topic
Display Mode
Topic Options
Author
Message
yb751
yb751
Posted Thursday, June 21, 2012 10:01 AM
Grasshopper
Group: General Forum Members
Last Login: Wednesday, April 17, 2013 12:52 PM
Points: 19,
Visits: 102
Hi folks,
I have a question in regards to a design I've been pondering. Perhaps i'm merely over analyzing the problem but I wouldn't mind some input.
I have a raw table that is used to collect large amounts of statistical data. Right now a web application hits this table directly and of course it is inefficiant and slow. I'm trying to redesign to process by having a job that parses through and summarizes the data and outputs it to a staging table before then adding it to a small table that will be exposed to the web application. I have this working great and seeing huge performance gains in a test environment.
My concern (and it might not be warranted) is with the updating of the final table. It needs to be refreshed every hour with the new statistics. Keep in mind as well that the web application will sometimes query the table thousands of times in a span of a few minutes. My thoughts was to have a bit field let's say "isNew" in the destination table that is defaulted to true as new data comes in. (The calling stored procedure always grabbing data from rows where "isNew" is false.) Then I delete "old" rows then change all rows makred as new to old. Making them available once again and ready for the next data load.
The resulting table should never grow beyond 10,000 rows thus the point of trying to keep it small, accessible and fast. Does anybody see this solution causing issues with a query returning no data in that small timeframe when I do the DELETE/ALTER or causing any kind of significant delay or wait to the application. Is there a beter way? Sorry about the verbage folks and any comments are appreciated.
Thanks,
Post #1319432
Lynn Pettis
Lynn Pettis
Posted Thursday, June 21, 2012 10:14 AM
SSC-Insane
Group: General Forum Members
Last Login: Today @ 5:20 PM
Points: 21,602,
Visits: 27,428
Assuming that you are doing this update in a stored procedure, I would do something more along the lines of this psudo code:
... prep work
set transaction isolation level serializable;
begin transaction
begin try
truncate destination_table;
insert into destination_table;
commit transaction
end try
begin catch
rollback transaction
... other error code as needed
end catch
end -- end of update procedure.
Lynn Pettis
For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here
or
when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here
and
here
Managing Transaction Logs
SQL Musings from the Desert
Fountain Valley SQL
(My Mirror Blog)
Post #1319439
GilaMonster
GilaMonster
Posted Thursday, June 21, 2012 10:27 AM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 3:07 PM
Points: 37,687,
Visits: 29,946
This actually sounds like a case for partitioning. Partition the main table, make sure the staging table is identical (indexes, constraints, columns, etc) then to move the data from staging into main you could just add a new partition to the main table and switch that new partiton with the staging table. Metadata operation, near instant.
Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild
: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter
We stand on the bridge and no one may pass
Post #1319447
Lynn Pettis
Lynn Pettis
Posted Thursday, June 21, 2012 10:29 AM
SSC-Insane
Group: General Forum Members
Last Login: Today @ 5:20 PM
Points: 21,602,
Visits: 27,428
GilaMonster (6/21/2012)
This actually sounds like a case for partitioning. Partition the main table, make sure the staging table is identical (indexes, constraints, columns, etc) then to move the data from staging into main you could just add a new partition to the main table and switch that new partiton with the staging table. Metadata operation, near instant.
This works really fast. Only thing is, you need to be using the Enterprise Edition of SQL Server. What edition are you using?
Lynn Pettis
For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here
or
when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here
and
here
Managing Transaction Logs
SQL Musings from the Desert
Fountain Valley SQL
(My Mirror Blog)
Post #1319449
yb751
yb751
Posted Thursday, June 21, 2012 11:04 AM
Grasshopper
Group: General Forum Members
Last Login: Wednesday, April 17, 2013 12:52 PM
Points: 19,
Visits: 102
Yes, I am using Enterprise edition. Partitioning is not something I have yet experimented with but that sounds like a great solution. Thanks for the idea.
Post #1319477
Lynn Pettis
Lynn Pettis
Posted Thursday, June 21, 2012 11:06 AM
SSC-Insane
Group: General Forum Members
Last Login: Today @ 5:20 PM
Points: 21,602,
Visits: 27,428
Since you are using Enterprise Editon, I'd go with Gail's suggestion.
Lynn Pettis
For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here
or
when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here
and
here
Managing Transaction Logs
SQL Musings from the Desert
Fountain Valley SQL
(My Mirror Blog)
Post #1319479
yb751
yb751
Posted Thursday, June 21, 2012 11:12 AM
Grasshopper
Group: General Forum Members
Last Login: Wednesday, April 17, 2013 12:52 PM
Points: 19,
Visits: 102
GilaMonster (6/21/2012)
This actually sounds like a case for partitioning. Partition the main table, make sure the staging table is identical (indexes, constraints, columns, etc) then to move the data from staging into main you could just add a new partition to the main table and switch that new partiton with the staging table. Metadata operation, near instant.
Just a quick question regarding this method. This loads the 'new' data into the main table quickly but you still end up with the old data in that table. As such could result in unwated data...or perhaps I read it incorrectly.
Post #1319486
Lynn Pettis
Lynn Pettis
Posted Thursday, June 21, 2012 11:14 AM
SSC-Insane
Group: General Forum Members
Last Login: Today @ 5:20 PM
Points: 21,602,
Visits: 27,428
yb751 (6/21/2012)
GilaMonster (6/21/2012)
This actually sounds like a case for partitioning. Partition the main table, make sure the staging table is identical (indexes, constraints, columns, etc) then to move the data from staging into main you could just add a new partition to the main table and switch that new partiton with the staging table. Metadata operation, near instant.
Just a quick question regarding this method. This loads the 'new' data into the main table quickly but you still end up with the old data in that table. As such could result in unwated data...or perhaps I read it incorrectly.
You would also swap out the old data. This means each set of data will have to be in its own partition.
Lynn Pettis
For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here
or
when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here
and
here
Managing Transaction Logs
SQL Musings from the Desert
Fountain Valley SQL
(My Mirror Blog)
Post #1319489
yb751
yb751
Posted Thursday, June 21, 2012 11:22 AM
Grasshopper
Group: General Forum Members
Last Login: Wednesday, April 17, 2013 12:52 PM
Points: 19,
Visits: 102
Hmmmm...just quickly reading over msdn articles on switching it seems you can only switch a partition with an empty one. So then I would see it as a three partition cycle.
1. Staging -> Holding
2. Main -> Staging
3. Holding -> Main
4. Delete Staging
or perhaps simply
1. Main -> Holding
2. Staging -> Main
3. Delete Holding
Thanks folks, I'll have to do some more reading and testing but it sounds promising.
Post #1319501
GilaMonster
GilaMonster
Posted Thursday, June 21, 2012 11:35 AM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 3:07 PM
Points: 37,687,
Visits: 29,946
Typically it's done like this:
Load new data into staging
Add a new partition to main
Switch new partition in main and staging (now staging is empty)
Switch partition containing old data with staging
Merge empty partition in main table
Truncate staging.
Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild
: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter
We stand on the bridge and no one may pass
Post #1319509
« Prev Topic
|
Next Topic »
22 posts, Page 1 of 3
1
2
3
»
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
