SQL Server Agent replacement

  • Friends,

    I have a server, inherited, SQL Server with more than 150 jobs using ETLs, direct invokations for SPs, etc.

    This server, only job  is executing those jobs, because there are no user databases associated.

    I am just thinking, if could be a better way to program those tasks or my only option is to live with this server. ??

    Could be a better way to program this tasks ??

    Thanks for your ideas

  • It sounds like you have an integration services server - which would have SQL Server Integration Services installed.  For the ETL processes - review how they are configured...are they referencing packages in the file system or do they reference a catalog or package store or MSDB?

    If this is - in fact - an integration services server, then there isn't anything you need to do...it was built to execute ETL processes (and it appears, other related jobs).  One thing you can consider for this type of environment - upgrade to 2016 (2017/2019) - and migrate to the Integration Services Catalog (if not already being utilized).  This would enhance the ability to manage those SSIS packages as projects and allow for better management of different configurations.

    Jeffrey Williams
    “We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”

    ― Charles R. Swindoll

    How to post questions to get better answers faster
    Managing Transaction Logs

  •  

    Jeffrey,

    Thanks for your ideas, but this server packages are deployed in the file system, and called via SQL Server Agent.

    I have found, this old thread, I don't know, if still is valuable

    https://www.sqlservercentral.com/forums/topic/alternative-to-sql-server-agent.

    thanks for your support.

  • Does it work? What are the hassles of running it this way?

     

    I'm a big fan of using things that work, not changing them without a good reason.

  • So - you have a bunch of SSIS packages stored in the file system and SQL Server Agent jobs are setup to execute those SSIS packages?

    If that is the case, then why do you want to change it?  You have an integration services server setup and configured to manage all SSIS (ETL) processes - it does not need to be changed.

    How would swapping out SQL Server Agent for some other scheduling product make it easier to manage?  It won't save you any money because that server still needs to be licensed the same as it currently is licensed.  Other than increasing the cost (licensing for the new scheduling service, maintenance, management, etc...) - there is no advantage to making this kind of change.

    Again - as a recommendation, I would recommend that you look at upgrading to a later version and implementing the SSIS Integration Services Catalog.  This will give you much better control over those packages - as well as some built-in reporting...

    Jeffrey Williams
    “We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”

    ― Charles R. Swindoll

    How to post questions to get better answers faster
    Managing Transaction Logs

  • Folks,

    Thanks for your ideas, is clear now to me, that only I need is to have a plan that helps me to use what I already have.

    Thanks again.

  • I do have days when I wish Microsoft would offer SqlAgent as a standalone product. I've tried a number of job management systems, and I continually come back to SQLAgent as the easiest and best.

    Luther

     

  • I think Agent works really well in many cases. There are enterprise schedulers, and most cost money because they handle complex things. I agree, it's generally worked very well for me. Even better than Windows Scheduler for things.

     

Viewing 8 posts - 1 through 7 (of 7 total)

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