Data Quality Tools, Mailing Software, Lists, NCOA, Data Enhancements

 | Shopping Cart Buy | Newsletters | Search

    Products         Solutions       Downloads & Trials       Support          Resources         Lookups       Contact Us  

Logged in as: Guest Search | Active Topics |

Optimizing Sql Server Options · View
Harry101658521
Posted: Thursday, May 19, 2011 11:19:57 AM
Groups: Member

Posts: 5
Is there anything I can do in Sql Server to speed up MatchUp's performance? For instance, would it be worthwhile to create an index on the ZipCode field?
Paul Nelson
Posted: Friday, May 20, 2011 10:32:02 AM
Groups: Administration

Posts: 90
Every little bit counts in regards to speeding up the processing of your files. There are many factors involved that can slow processing your SQL files. Here are some pointers from our help file....

Network and file formats.
Slow network topology and/or protocol equals poor results. In general, databases process faster on a local hard drive compared to a network hard drive - there's less hardware between the application (MatchUp) and the data. If you're processing a large file on a regular basis, relocating the database on a local drive may save you lots of time.

File format and file structure play a role in processing speed as well. dBASE, Flat File, and SDF files are processed rather quickly. SQL Server, DB/2, and Oracle process slower than dBASE, but the speed hit is largely dependant on the network topology and load. Delimited and ragged SDF files are processed much slower. ODBC files are typically processed rather slowly as well, but it is largely dependent on the ODBC driver used. Performing file updates also adversely effect MatchUp's processing speed. Scattering, Status codes, Count Fields, etc. all slow the process.

Table Structure:
Although field name and field position are critical to proper operation, field sizes can be extended if necessary to accommodate larger lookup strings. However, this should be done economically, as excessively large lookup fields will slow performance.

Let me know if this helps.



Harry101658521
Posted: Tuesday, May 24, 2011 1:58:59 PM
Groups: Member

Posts: 5
Thanks. This was very helpful. I moved the database to the local hard drive, and it ran an order of magnitude faster -- 4.5 hours instead of 40+ hours.
Users browsing this topic
Guest


Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Powered by Yet Another Forum.net