December 2, 2016 at 9:20 am
David.Poole (12/2/2016)
I think I would push for the DDL commands to be part of the ANSI SQL Standard before setting them up in SQL Server.I think there should be a new category of commands rather than lump them under DDL. Service Definition Language (SDL) or something similar. JCL is probably copyrighted.
SDL (Service(s?) Description Language) is a rather ancient (pre-2000) Microsoft language, which was part of the basis for WSDL (a combination of MS SDL and IBM NASSL put together in 2000 by MS, IBM and Arriba for specifying Web Services working with SOAP).
JCL (Job Control Language) is two distinct IBM scripting languages (JCL for DOS and successors and JCL for OS and succesors). JCL (Java Class Library) was Sun, I think, so maybe now it's Oracle. You can also rule out SCL (System Control Language) which was ICL and is now Fujitsu and SCL (Structured Control Language) which is loosely based on Pascal and is used for programming PLCs and defined in an International Electrotechnical Commission standard.
That sort of problem could probably be avoided by using MSJDL (job definition language) and MSJML (job manipulation language) (JML is of course Java Modeling Language and JDL is Jewish Defence League, so the MS prefix would be needed to make those strings safe from confusion).
Tom
December 2, 2016 at 10:43 am
We don't need a Job Description Language, jobs can already be scripted out to T-SQL stored procedure commands. Likewise no need for a special Server Description Language; there are stored procedure calls for creating other non-ANSI objects like linked servers, replication, and server settings. Whatever happens in the background whenever we right-click on an object in SSMS and choose 'Script as..', a DDL comparison / sync tool can leverage that same process for comparison and deployment.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 2, 2016 at 2:58 pm
Definitely! In the environment here, our databases are on shared servers, and as a dbo and developer, I have NO access to create, modify, schedule or run jobs in the shared environment. Not allowed, and never will be, because any job would be accessible to all and every dbo on the server (I'm told).
It is possible to open tickets to get a job created and scheduled, but unless the job is simple and clearcut, it is an ordeal to get a more complex job created, debugged and tested through the IT ticketing system.
- Alan Hirst
December 5, 2016 at 5:36 am
David.Poole (12/2/2016)
I think I would push for the DDL commands to be part of the ANSI SQL Standard before setting them up in SQL Server.I think there should be a new category of commands rather than lump them under DDL. Server Definition Language (SDL) or something similar. JCL is probably copyrighted.
That is most likely to help the idea get traction.
It is something that I think many would benefit from and would appreciate.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 5, 2016 at 7:35 am
I think it's a great idea. That would give us better control, tracking, and implementation.
December 5, 2016 at 2:09 pm
I would certainly like to see SQL Agent Jobs get a bit more development, and being able to maintain jobs at the DDL level sounds like the best way to go.
Already with Resource Governor we have Microsoft extensions to DDL, so adding more extensions for job management should not be a barrier.
Among the many things I would like to see with Job Management are:
1) (Absolutely the top item!) Grouping of jobs into Suites, with inter-job dependencies within a Suite. This would allow a DBA to specify which jobs had to complete successfully before a subsequent job could start processing, and to specify that certain jobs could run in parallel.
2) Inter-Suite dependencies. This would automatically trigger a dependent Suite when all predecessors have finished. A dependent Suite may be on the current or different SQL Instance.
3) Graphical representation of job execution times. This should show which jobs ran during a given timeframe and when each instance of each job ran. I know we can put this together ourselves as a SSRS report but we should not have to do this level of work.
4) Allow multiple Schedules for a given Job. For example this could allow the job to be set to run Mon-Fri every week, plus run on Sat on x given week every month.
5) SQL Agent functionality on Express Edition, even if it was only possible if the Express instance was enrolled as a Target Server.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
December 8, 2016 at 2:19 am
jay-h (12/2/2016)
Or we could go completely the other way.As it is, the job system is an awkward fit into the SQL management world. You can do a lot with it, but it's still in some ways shoved into the same box as SQL servers.
Maybe it should be a completely separate entity-- one instance with a job oriented interface, that controls all jobs in all the servers in a farm, department or organization, with top down tools for managing at all levels.
I've been told by a Microsoft Field Engineer that the SQL Agent code base hasn't been changed much for the last 10 years or so. He expects the SQL Agent will be removed in a future version and jobs must be handled using the OS scheduler (or a third party application).
December 8, 2016 at 2:23 am
Sorry - previous post was duplicated
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply