John W. Colby
jwcolby at colbyconsulting.com
Tue Sep 14 14:11:30 CDT 2004
In fact I ended up just using single drives on each SATA channel, no raid of any kind. I was focused on getting the data into the db and splitting the db into 4 files where each file could get as large as 250g was my biggest priority. Now that the db is in, I may consolidate some of the files and throw them on a Raid0 array to up the read performance. What I was really talking about was whether SQL Server took a performance hit just by splitting a table across 4 files. John W. Colby www.ColbyConsulting.com -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francisco Tapia Sent: Tuesday, September 14, 2004 2:11 PM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] Database Files When the drives are configured as Raid 5, I understand that it improves read performance, which you will you've mentioned this db would be doing mostly. You never mentioned if these drives ere Raid 5 or not. On Tue, 14 Sep 2004 11:47:20 -0400, John W. Colby <jwcolby at colbyconsulting.com> wrote: > In the quest to get sufficient storage to do the nVLDB bulk mail > database I split the database into 5 containers, 4 for storage and one > for the log file. Understand that this is still to this point, and > likely will remain just a single table. Does anyone understand the > usage of database files well enough to tell me whether splitting it > into multiple pieces like this causes performance degradation or > enhancement? I have read that using different files for different > tables can enhance performance, but what about where it is all just a > single table? > > In the end I may need to leave it as multiple files since processing > such as adding indexes can temporarily inflate the files by almost > double. When I am done they shrink back down nicely but during > processing they get big. > > BTW, as to the actual size of the database (one table, 164 million > records, 660 fields, 3000+ bytes / record) - it used 4 files of ~40 > gbytes after shrinking. I added in the PK (autonumber) and indexed > the state code field and ended up with 2 files of 40g and 2 files of > 86g after shrinking. So the indexes added a LOT of size to the > database. > > John W. Colby > www.ColbyConsulting.com > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- -Francisco <a href="http://spreadfirefox.com/community/?q=affiliates&id=0&t=86"><i mg alt="Get Firefox!" title="Get Firefox!" src="http://spreadfirefox.com/community/images/affiliates/Buttons/125x50/tak ebacktheweb_125x50.png"/></a> _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com