Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««123

What is the Maximum Page Size in SQL Server 2000? Expand / Collapse
Author
Message
Posted Friday, May 19, 2006 10:30 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Saturday, January 21, 2012 5:26 PM
Points: 543, Visits: 38

**If you never hear from me again, you know I went to far with this missive.**

But if you had to store all the phone calls in America. 

With Content: I can't see it as BLOBS.  Although, its only mono 8kbs 11-22khz. with the right compression one could get it down to about 3 mb's / hour of one conversation.

If its brute force, I'll include fax machines, pagers and such placing number of phone numbes in the US to be around 1 Billion.

Say ten percent usage at any time. 100 Million 24/7.

3x24 72 mb's per call x 100 million 7.2 billion MB's per day.

Which comes in around 72 Terabytes of data. Daily.

If I took one of these:

XKSS Series III
Ultra High Capacity 6U SATA II RAID Server

Up To 18 Terabytes Storage - Dual 64 Bit Xeon's - 800Mhz FSB - DDR2 Memory
- Transfer Rates over 800 MB/s for RAID 5 Reads and 380 MB/s for RAID 5 Writes

The biggest I found with a cursory look.  I upped the drive sizes to terabyte each but then

There is one problem. I'm still only at 32 Terabytes a piece.

 

Next problem. 6 terabytes an hour. 100 gigabytes a minute. 1.6 gigabytes per second.

Well over the bandwidth of the all the call data.

One might say well have multiple recordings in different sites.  The duplication out of state occurs.  Still a possiblity but it would no longer be 'national'.

I'm thinking its not that the NSA wouldn't record all the calls but I think they just can't do it carte blanche.

Now its a different story were some speech to text be involved.

Any other thoughts?




Post #281472
Posted Friday, May 19, 2006 10:32 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Saturday, January 21, 2012 5:26 PM
Points: 543, Visits: 38
I for the record, do not work for the above company. I just wondered if were going to push page size issues. This task, phone recordings, might be one that could bring up that issue. Plus it's timely.


Post #281474
Posted Sunday, May 21, 2006 12:53 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: 2 days ago @ 1:40 AM
Points: 222, Visits: 44
Thank You for very interesting info...
Post #281601
Posted Monday, May 22, 2006 7:58 AM


Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, January 13, 2012 6:10 AM
Points: 8, Visits: 36

This article was a great piece of information!  Great work!  I think that we all appreciate the time and effort that you put into this research.  I will keep this all in mind for future reference.

Thanks,

~D




Thanks,

~DH
Post #281732
Posted Monday, May 22, 2006 9:07 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, January 09, 2012 2:28 PM
Points: 43, Visits: 58
Steve... it never ceases to amaze me the lengths that you go to provide us every bit of information needed to keep our 'sanity' and the information needed for us to succeed.  And it never ceases to amaze me just how you find these issues and spend dedicated time in researching them for us.  Your efforts have always been, in the past and will continue to be in the future, much appreciated!  Thanks for your dedication to this site and to us (your loyal fan base).  Press onward!  Scottye
Post #281804
Posted Monday, May 22, 2006 11:19 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Friday, October 07, 2011 12:25 AM
Points: 79, Visits: 176
Steve,

Great job! I've run into this a few times. And it has always puzzled me why the 8060 wasn't correct. Now I know. Thanks!


Gary Johnson
Sr Database Engineer
Post #281854
Posted Sunday, June 25, 2006 8:50 PM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, February 02, 2012 6:49 PM
Points: 1,854, Visits: 1,490
The extra 14 bytes is only needed for records in heap pages. Here's why - heap records do not have keys, by definition, so the only way to reference them from non-clustered index rows is using the physical RID - a combination of the physical page and slot number. If a heap record changes size such that it no longer fits in the same slot, it has to move to another page, but we don't want to have to go and update all the non-clustered indexes that point to it. So we leave a forwarding-record that points to the new location in the heap, and the new record has to point back to the forwarding record. We always have to ensure we have enough space to add the 14 bytes to any heap record, hence the reduction in maximum row size for heaps.

This doesn't apply to clustered indexes, where non-clustered indexes store the clustering keys of clustered index records and are impervious to the clustered index records moving around as they change size.


Paul Randal
CEO, SQLskills.com: click here to join our community!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine and SQL Server Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
Post #289992
Posted Monday, November 06, 2006 9:38 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, March 07, 2007 9:35 PM
Points: 1, Visits: 1

Artical was very Useful.

I tried the below query

create table MyTest 
 (       mychar1 char( 8000) 
         , mychar2 char( 39), 
         , myvarchar3 Varchar( 8000), 
         , myvarchar4 Varchar( 8000), 
         , myvarchar5 Varchar( 8000) 
  
Then I inserted data.

Insert into MyTest values('r1','r1','12345678901',null,null)  - Not Working(row size =8061)

Insert into MyTest values('r1','r1','1234567890',null,null) -Working

Insert into MyTest values('r1','r1','123456789','1',null) -Not Working(row size =8062)

Insert into MyTest values('r1','r1','1234567','1',null)- Working

Insert into MyTest values('r1','r1','123456','1','1') -Not Working(row size =8062)

Insert into MyTest values('r1','r1','1234','1','1')-Working

In the above case, is the bytes allocated ( 10 + 2)  for backpointer is used for data at runtime ?

Please can you explain this situation!!

 

Post #320837
Posted Monday, June 18, 2007 8:40 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, November 02, 2011 9:14 AM
Points: 36, Visits: 12
Here it is 6 years later and still there is no better explanation of the problem of page size and the 8060 vs 8039 discrepancy. Your article is a very good resource and I thank you for it. I also created a simple excel file to compute the size it can be found at:

http://thom.pantazi.com/downloads/SQLServerRowSizeCalculator.xls

It assumes you will sum the sizes of the columns. although you can do it inline as I did.



Post #374646
Posted Saturday, August 28, 2010 2:02 PM


One Orange Chip

One Orange ChipOne Orange ChipOne Orange ChipOne Orange ChipOne Orange ChipOne Orange ChipOne Orange ChipOne Orange ChipOne Orange ChipOne Orange ChipOne Orange ChipOne Orange Chip

Group: General Forum Members
Last Login: Today @ 3:34 PM
Points: 28,397, Visits: 22,188
You'd figure that after 7 hears on this site, that I'd have run into this fun and informative article by now. As an update, the SQL Server documentation now does have the rough explanation of the 24 bytes in heaps that Paul Randal described.

Well done to you both. Steve, thanks for writing it.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #977017
« Prev Topic | Next Topic »

Add to briefcase «««123

Permissions Expand / Collapse