Delete jobs - Testing and preparing for Production
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
I plan to use a suite of delete jobs and would like to test the job(s) in lower environments and promote up our companies environment stack. The filter criteria for the job will be applicable for all environments.
Any recommendations or experience on a potential process for this?
Thoughts so far
- Recreate the job in each environment - While my filter criteria is extremely straight forward, manually creating in each environment leaves room for manual error.
- Import XML/Update Set - This option would have me create the job in DEV, and promote up the stack via XML or Update Set. This option falls short for two reasons. First, as soon as I run the job in DEV, the state moves to Complete and it gets its rollback relationships. Second, because Delete jobs may be made directly in production there could be number collisions.
#deletejobs
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
In my instance Scheduled job are in the sysauto_script table. there is no State field. You can export those records and import in higher instance, then run the jobs manually if desired and 'Run' field is set to "On Demand"
I don't understand how running delete jobs would lead to number collisions.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
The delete jobs I am referring to are stored in the table "sys_dm_delete". It is part of the System Data Management application.
Here is the situation in my head for number collision. Lets say I create DM0001001 in Development. Meanwhile, in Production a separate team may have created DM0001001 in Production for an ad-hoc delete. If I were to export/import the XML from Development into Production - the number is already taken.
