http://www.sqlmag.com/authors/author/author/5034413/rsscomment/5034413en-USFri, 25 May 2012 10:26:51 GMTFri, 25 May 2012 10:26:51 GMThttp://www.sqlmag.com/article/business-intelligence/getting-started-with-parallel-data-warehouse#commentsAnchorTue, 12 Apr 2011 21:07:00 GMT
From the list of new commands it is evidently seen that the principals to divide information in PDW are the same like in usual Federated Distributed Database. It was done by using horizontal tables splitting. But, all management of distributed queries was shifted to the primary PDW node. Moreover, the old-fashion idea of manual data distribution was embedded into T-SQL syntax. However, it is still crucially important to design a database structure properly. Otherwise, all you investments will be spent for nothing. According to this, it could be very interesting to compare performance of Federated Distributed Database and Parallel Data Warehouse because theoretically they are quite similar. Nevertheless, thus it is not so easy to get an access to really operated Parallel Data Warehouse solution, I am steal curious how faster is it in compare with the predecessor technology operated on base of Federated Distributed Database architecture with the same amount of hardware. For more information: http://sqlconsulting.wordpress.com/2011/04/13/inside-of-parallel-data-warehouse/]]>afomchenkoTue, 12 Apr 2011 21:07:00 GMThttp://www.sqlmag.com/article/business-intelligence/getting-started-with-parallel-data-warehouse#commentsAnchorhttp://www.sqlmag.com/article/business-intelligence/getting-started-with-parallel-data-warehouse#commentsAnchorFri, 06 Aug 2010 07:31:42 GMT
The article looks excellent. Going through this I have a question. Can we move existing database to PDW? What are the pre-requisites? For example, I have fact table which is huge and doesnt have partitions implemented, how can I store that in PDW. Request you to throw some light on this.]]>SubnivisFri, 06 Aug 2010 07:31:42 GMThttp://www.sqlmag.com/article/business-intelligence/getting-started-with-parallel-data-warehouse#commentsAnchorhttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorFri, 18 Apr 2008 10:06:03 GMT
Hi andrewn2008, Thanks so much for your feedback. You ask a lot of great questions, which could end up being topics for future storage articles. We will definitely keep your comments in mind when we are acquiring and scheduling storage articles for SQL Server Magazine. Thanks again! Megan Bearly Associate Editor, SQL Server Magazine mbearly@sqlmag.com]]>meganbearly Fri, 18 Apr 2008 10:06:03 GMThttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorhttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorTue, 15 Apr 2008 16:05:58 GMT
I hope the author can update his article as somethings have changed. Vitesse no longer makes SAS Expanders. And it looks like Supermicro SC933 is a better fit for a 16-bay chassis since the LSI Expander card is included, however I think the backplane is only SAS drives, not SATA. I did manage to find a chenbro expander card, but they sell two models, and if you want the one described in the article, it would take forever to ORDER one. I heard the lead time is about 6-weeks.... He said that they would come out with the results by plugging in SAS drives but no results or updates were forthcoming. I guess Chenbro wanted their chassis back. Has anyone built this model yet with today’s available resellers? And preferably on both SATA and SAS in your chassis so you can put your OLTP on SAS and your storage needs on SATA?]]>AndrewTue, 15 Apr 2008 16:05:58 GMThttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorhttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorTue, 25 Mar 2008 07:45:37 GMT
Excellent Article, Thank you.]]>GrahamTue, 25 Mar 2008 07:45:37 GMThttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorhttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorThu, 13 Jul 2006 11:19:03 GMT
I am also curious about the RAID configuration in this scenario? I heard that there is interoperability issues between LSI SAS HBA and Vitesse SAS expander but not sure they are the ones used in this setup.]]>jingtau Thu, 13 Jul 2006 11:19:03 GMThttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorhttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorFri, 03 Mar 2006 07:02:53 GMT
I’m also curious what (if any) RAID configuration was used as well as the location of the database drives. If you didn’t use any RAID would you consider redoing the test with in applied so we could see how much of an impact this would have on performance? Enterprise customers would likely be willing to compromise on some amount of performance if we retain the reliability we get in a SAN. Thanks for considering & for the article itself.]]>toennitm Fri, 03 Mar 2006 07:02:53 GMThttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorhttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorFri, 03 Mar 2006 04:48:33 GMT
To trimai, to fully utilize PCI-X bus, you need to know deep knowledge of the hardware platform. (e.g. how many buses there in the chipset, which and which slot share the same bus). Bus always wide than HBA, so it makes great sense to use two HBA on one bus. No one will stop you to only use 4 cards, but with two more, you get more throughput. To THEFox, $230 is not far away from $178, isn’t it? Buying in a bunch always get cheaper, I reckon. Jim Gray’s paper is in more details. Something lack from this article is the RAID configuration and DB filegroup setting up. And what about OLTP? How good will this system respond to Random access? SAN maker’s easy money day should over ASAP.]]>DongFri, 03 Mar 2006 04:48:33 GMThttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorhttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorWed, 01 Mar 2006 13:39:09 GMT
In Table 1, the typical market cost of 64 Seagate 400GB drives is $11,340. This comes out to $178 per drive. Where can I obtain these drives at that cost? The best I can do is $230.]]>LarryWed, 01 Mar 2006 13:39:09 GMThttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorhttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorWed, 01 Mar 2006 13:02:55 GMT
Hi - The author has this response to the discrepancy on the figues: From Rich Johnson: The graphic I saw was a picture of memory cards that said 16 x 4 GB which would be 64 GB of memory. It should be 8 x 4 GB cards. Is that what the reader saw? Its kind of small but if you really look at the diagram and the fact we refer to 32 GB of main memory than that’s a discrepancy. Regards, ---------------------------------------------- Rich Johnson Architect Business Intelligence Solutions for the Retail & Hospitality Industry]]>djmay Wed, 01 Mar 2006 13:02:55 GMThttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorhttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchorMon, 27 Feb 2006 12:08:00 GMT
Article text and Figure 1 don’t match. Article mentions 6 LSI SAS HBAs, and the figure shows only 3 (1 dual, 2 single). It would make sense to reduce the cards to 4 or fewer so that each could run on the host computer’s 133Mhz PCI-X slots. Also, the article mentions 32GB of RAM, while the figure shows 64GB. Why the difference? Which setup was used to post the results?]]>TRIMon, 27 Feb 2006 12:08:00 GMThttp://www.sqlmag.com/article/server-systems/pare-down-and-power-up#commentsAnchor