January 25, 2009 at 12:06 am
Hi evryone,
i need your graat help by suggesting the solution to my problem. Im using my server for ETL process. we are expecting 30 - 35% increase in datavolume by the next month.
our ETL cycle starts from 10.30 and ends between 4.30 and 5.30, sla time is 6.30 (should not cross that). but wht worrying me is increase in data volume my increase this ETL load and report time. How can i improve my server performance.
we have implemented horizontal partioning of some facts and aggregates using partitioned views. performing insertions into underlying tables than inserting into views. using No lack table hint in select queries, updating statistics daily nad reindexing weekly
server :hp prolient 64 bit
sql server 2005 sp2
memory config :AWE enabled, total 16gb and available :1.12gb
virtual : 23.38 Gb available 8.55 Gb
pagefile 7.99 Gb
pagefile : c:\pagefile.sys
Database : divided onto files and filegroups mdf and 6ndf files.
all these files are stored on M:drive {san}
Review this partioning, indexes and server config and our ETL stratergy and suggest me the ebneficial measures
January 25, 2009 at 6:13 am
AWE should not be enabled on 64bit systems.
Does the server have 16GB of memory total? If there is only 1.2GB available you are choking the OS, that can seriously impact things that the ETL process can require.
Do you have the "Lock Pages in Memory" setting on for the service account that you are using?
You mention the virtual memory, you should not be paging at all, so this should be irrelevant, if you are seeing paging it is because you either have only 1.2GB for the OS, or it's paging out SQL processes in order to run OS processes.
Make a start with those things and if you get no improvements then you'll need to provide schemas, scripts and data examples.
January 25, 2009 at 11:11 am
Couple things...
Nolock is not a good thing to add everywhere. Are you aware of the problems it may cause and do you feel that the risks of bad data are acceptable?
What's SQL's max memory set to? From the sound of things, it should perhaps be lowered.
Are the log files also on M? If so, why?
What's the RAID level of the SAN drives and are they dedicated?
Is it 64 bit SQL? Enterprise edition? Standard edition? If enterprise, have you considered partitioned tables, rather than partitioned views?
As for advice, profile the ETL process, find the slowest portion and then look at optimising that. Looking at the entire thing in one go is not a good idea. You need to identify the pain points and fix those, then find the next most problematic point and fix that, etc, etc
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 27, 2009 at 3:31 pm
In addition to the other suggestions, make sure that:
1) Join columns are indexed
2) Indexes have the proper freespace and are reorganized / rebuilt as often as needed to keep them functioning well
3) Queries do not do functions on table columns unless absolutely necessary, esp. on indexed columns. For example, instead of:
WHERE YEAR(datecolumn) = 2008 AND MONTH(columnname) = 2
write:
WHERE datecolumn >= '20080201' AND datecolumn < '20080301'
4) Tempdb has at least one data file per processor core
Since you have only one SAN drive, you cannot be using RAID 1 for logs and RAID 5/10 for data. This will affect your performance as well.
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
January 27, 2009 at 8:17 pm
Stop using SSIS for ETL. Use BULK INSERT and some good T-SQL programming, instead.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2009 at 8:32 am
Don't use Table or View as your data access method when loading or transferring data. This apparently uses a cursor behind the scenes, and as a result kills your ETL. Or at least means it runs forever. Rather than use table or view, on say vwMyETLSource you are actually better off using SQL Command for data access method with SELECT * FROM vwMyETLSource.
Goes against the grain I know
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply