'Invalid access to memory location' error in Jobs but not in BIDS

Question

'Invalid access to memory location' error in Jobs but not in BIDS

mckyn

Grasshopper

Points: 15
More actions
November 20, 2014 at 12:40 am

#150791

Hi,
On running the parent package in nightly schedule job gives an 'Invalid access to memory location' error but running from MS VS works fine without error. Log file giving this message 'AppDomain 33 (SSISDB.dbo[runtime].32) is marked for unload due to memory pressure'. Strangely, parent package runs successfully after manual starting the job. I would appreciate any tips to resolve the error.
Thanks

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply

Phil Parkin SSC Guru Points: 247183 More actions · Answer 1

mckyn (11/20/2014)
Hi,
On running the parent package in nightly schedule job gives an 'Invalid access to memory location' error but running from MS VS works fine without error. Log file giving this message 'AppDomain 33 (SSISDB.dbo[runtime].32) is marked for unload due to memory pressure'. Strangely, parent package runs successfully after manual starting the job. I would appreciate any tips to resolve the error.
Thanks

When you run it in VS, it's running on your machine. The error you are seeing is happening on the server, so it's not really a worthwhile comparison.

The low-memory message seems fairly self-explanatory ... you need to investigate that.

Koen Verbeeck SSC Guru Points: 259197 More actions · Answer 2

Typically this is some sort of memory pressure issue. It might occur only during your nightly run.

Set up some monitoring to see what is going on at night.

Pointers:

* a lot of stuff running in parallel?

* connection managers set to RetainSameConnection?

* connection managers with the property MARS set to true?

Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP

mckyn Grasshopper Points: 15 More actions · Answer 3

Thanks for the responses.

Phil - I also did manually run the job from server itself using SSMS and it went fine. Will check again tonight.

Koen - Appreciate the tips you provided. In response to your questions. There are child packages that run in parallel but no not alot and no other jobs running in parallel. Records processed in average ranges from 60K-100K. The RetainSameConnection is set to False and also DelayValidation set to False.I will monitor the load tonight.

Apologies for my ignorance but i am cutting my teeth on this and am grateful for all your comments.

Thanks

Phil Parkin SSC Guru Points: 247183 More actions · Answer 4

mckyn (11/20/2014)
Thanks for the responses.
Phil - I also did manually run the job from server itself using SSMS and it went fine. Will check again tonight.
Koen - Appreciate the tips you provided. In response to your questions. There are child packages that run in parallel but no not alot and no other jobs running in parallel. Records processed in average ranges from 60K-100K. The RetainSameConnection is set to False and also DelayValidation set to False.I will monitor the load tonight.
Apologies for my ignorance but i am cutting my teeth on this and am grateful for all your comments.
Thanks

The fact that all is well when you run it manually from SSMS suggests that there may be other jobs running at the same time as this one when it runs in the evening, and that those jobs are all trying to consume their own chunks of memory.