Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Truncating a lot of data does it cause extreme memory usage.

2 views
Skip to first unread message

Hoardling1 via SQLMonster.com

unread,
Dec 3, 2009, 2:54:39 PM12/3/09
to
SQL Server 2008
I have a SSIS job that copies data and transfers it to another database. The
job is truncating the data. Now, the source database column sizes are large
and the destination size is smaller, but the data is small in size so most if
not all the data that is being truncated is not being lost. My question is
will that dramatically use more memory or is this something minor on memory
usage when I transfer it from one database to the other.

--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server-performance/200911/1

Will Alber

unread,
Dec 3, 2009, 3:01:05 PM12/3/09
to
Could you rephrase the question please - which process(es) are you concerned
with memory usage for?

"Hoardling1 via SQLMonster.com" <u43783@uwe> wrote in message
news:a00cca581e310@uwe...

> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4658 (20091203) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4658 (20091203) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


Russell Fields

unread,
Dec 3, 2009, 3:08:45 PM12/3/09
to
Truncating a table uses very little memory since it simply releases all the
extent allocations for the table being truncated. This happens very quickly.
Make sure that your table has ptjer table referencing it through a foreign
key constraint, since that will prevent the truncate statement from
executing.

RLF


"Hoardling1 via SQLMonster.com" <u43783@uwe> wrote in message
news:a00cca581e310@uwe...

Hoardling1 via SQLMonster.com

unread,
Dec 4, 2009, 2:22:24 PM12/4/09
to
I have a SSIS package that runs on a schedule basis. Everytime it runs my
memory max's out and my CPU processes max out. Now I am reviewing this SSIS
package and trying to figure out a way to tone it down. I have 2 ideas that
I am looking up. The SSIS package simply copies from 1 database to another.
Note there are like 6 of these copying process in this SSIS package running
at the same time. That I believe is problem 1, I think they should be
chained to fire after each one completes successfully to do another. The 2nd
problem I notice was some of these had a Source column with varchar(255) and
the destination was varchar(50) so the data has to be cut. I am trying to
figure out if the 2nd scenario is also having a huge impact on my memory
usage, RAM usage and CPU usage.

Will Alber wrote:
>Could you rephrase the question please - which process(es) are you concerned
>with memory usage for?
>

>> SQL Server 2008
>> I have a SSIS job that copies data and transfers it to another database.

>[quoted text clipped - 8 lines]


>> memory
>> usage when I transfer it from one database to the other.
>

>__________ Information from ESET NOD32 Antivirus, version of virus signature database 4658 (20091203) __________
>
>The message was checked by ESET NOD32 Antivirus.
>
>http://www.eset.com

--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server-performance/200912/1

Will Alber

unread,
Dec 4, 2009, 8:11:02 PM12/4/09
to
Making the copy processes less parallel will definitely help with memory
consumption - although if most of the processes are using little and one is
using a great deal the benefit may not be great - but as with most things
SQL Server a little experimentation goes a long way.

If you're going to keep your destination @ 50 chars, the select that
acquires the source data could cast the VARCHAR(255) to a VARCHAR(50), then
the memory requirement for that particular data flow _may_ decrease (or may
remain the same, but the data flow complete faster). SSIS sizes its buffers
based on the maximum row length - so a VARCHAR(255) will require 255 bytes
per row regardless of the actual content (or thereabouts - am unsure of NULL
handling in SSIS). Whilst choosing a reasonable size for a VARCHAR is more
of a data integrity issue in the database engine, the effects of an overly
large VARCHAR column on a SSIS dataflow can affect performance greatly.

"Hoardling1 via SQLMonster.com" <u43783@uwe> wrote in message

news:a01914dc87878@uwe...

> signature database 4661 (20091204) __________


>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4661 (20091204) __________

0 new messages