Indeed, but it does answer your question "how to schedule a job in HANA", doesn't it?
If your question was instead "does HANA have a native job scheduling mechanism?" the answer would be "no, not yet". And I do agree that this is "must" a requirement for any DB that has an intention to be #2 in the world, but I'm sure it will be there soon enough. In the meantime, you could use the workaround I mentioned, if necessary.
Out of curiosity: why do you think that scheduling is a must-have feature for a DBMS?
And to what extent do you think a DBMS should support scheduling?
E.g. Oracle had scheduling for years in rather simple state and came up with more complex options (like execution time windows, job dependencies etc.) only with the last major release.
And up to this day, these functions are not super-wide-spread.
Still my impression is that most companies that have scheduling requirements which can't be fulfilled by cron or something similar, usually go for scheduling systems that can bridge the gaps between different systems/databases.
So, what are the use cases that make a db owned scheduler inevitable?
As was announced at TechEd; the roadmap for SAP HANA Extended Application Services contains plans to deliver a first version of a scheduler with SPS6 and a more advanced scheduler which support things like event driven scheduling in SPS7. Therefore this is something which SAP development is actively working on now.
The point is that HANA is not just a RDBMS, it is intended to be RDBMS + Application Platform + EDW in the same platform. And any EDW or Application Platform without a job scheduler is not really a serious player.
I'm just a mere consultant passing forward what I hear from my* customers. 😉
A few cases where it might be interesting:
1) a predictive analysis scenario based on HANA PAL algorithms, where you have a learning procedure and a prediction procedure (e.g. Decision Tree). You execute your queries based on the prediction one, but you will want the learning procedure to update the learning dataset of the prediction model from time to time (since you have real-time transactional data being fed into the HANA system that might actually make the predictive model better each time it runs), but you don't want it to run on the same granularity of the queries (also not to impact the query execution time). Easiest way to achieve that would be to simply schedule the learning procedure;
2) a scenario similar to 1 (i.e. any procedure you might want to execute from time to time) but for which you might want to check other pre-reqs based on other database objects prior to triggering it (you could of course create a wrapper proc, but that would just increase maintenance);
3) a simple text file loading scenario based on IMPORT FROM command you want to trigger from the database itself, without relying on any external replication/ETL tools;
4) a "transaction + analytic" application on HANA, where you have a row table and a column table with the same structure. In order to not cause computational impact in smaller HANA boxes, specially if you have other concurrent applications on the same HANA box, you might want to skip any triggers on the row table to replicate the data to the column table; instead, if "near real time" is acceptable, you might just want to schedule a job to move data from one table to the other from time to time; (whaaat, a non real-time scenario in HANA!??! please don't burn me in the fire as a heretic :O)**
5) a "self-learning" optimized partition approach, where you have a procedure that reads the currently existing data, finds the best criteria to partition the data and calls partition functions updating the value definition of the partitions;
6) etc...
Of course most of these could simply be achieved by doing it on the OS level, but the point of a job scheduler is to maintain it in the same interface as the other DB administration assets, specially if you consider that HANA customers will be using more and more SolMan to centrally maintain (including job monitoring in) all SAP systems in the landscape. But, to be honest, IMHO, the job scheduling functionality needs to be there, but there's no need for a fancy UI, given that it provides a nice job scheduling API for external job schedulers, such as Control-M. And of course native integration to SolMan. 😉
The point is that, in the same way we're reevaluating all our applications and learning optimization points where it might make sense to bring application logic (without business logic) down to the Database level, there will also be cases where data-intensive scheduled activities might make sense to be brought from the application layer down to the Database layer as well, in order to achieve better performance.
PS: I'll not argue about BW x HANA. Again.
* Actually, our customers, my fellow colleague.
** At least until they come up with a "CREATE COLUMNROW TABLE" comand.
SAP HANA is a real time database, where you run the reports on-the-fly and the data is fetched faster. You should use the reporting tools to schedule the reports in time if necessary.
SAP HANA DB is not like the usual RDBMS. The way you operate and consume data from SAP HANA is different from other DB. I would recommend you to read the SAP HANA essetials book from the link http://www.saphanabook.com to better understand the SAP HANA DB.
if SAP wan't to be №2 in 2015 on the database market SAP must provide at least the same standard functionality as other RDBMS (MS SQL, IBM, Oracle, Sybase). Isn't ?
>looks like you like to focus on what HANA can't do ...
I am not marketing person, i am technical.
Again - i want to make clear understanding what HANA can do, what not. And we must be objective.
Sure I am a SAP employee as it could be easily checked by looking at my SCN profile.
And I think we have to agree to disagree here:
To serve the users better than the products that have been in the market for >30 years now in a virtually frozen situation without any real competition it's definitively not about providing all the features that others have.
Instead it's about to deliver value to the customer that can otherwise not be obtained.
Scheduling surely is not a high-demand core DBMS feature. It's a nice add-on to have - but not essential.
And although you neglect the NetWeaver market for DBMS, SAP still is the single largest Oracle re-seller. So from my perspective this is quite a market to break into.
In addition to that: HANA is just one of the DBMS products SAP markets.
Sybase ASE and IQ are also pillars of the overall DBMS strategy.
And as far as I understood the announcements, SAP - as a database vendor - has set this goal.
The goal was not set to be reached with HANA alone.
Concerning your "objective" tests - I haven't seen any query performance measurements from your side yet.
You compare data container sizes that are used completely different in IQ and HANA.
You compare insert performances for scenarios that are not what most users do most of the times.
(Where's the daily delta loading? I don't know about IQ, but is it required there to create secondary indexes to improve query runtime? What about data staging and aggregate creation to improve query speed?)
Based on the projects and cases I've been involved with HANA I can honestly say: the product is of course not as mature as many other DBMS (yet).
But hey: it's there for just about 1,5 years now.
And yet SAP BW, CRM, SMA all run on this DBMS.
How "old" had been the other DBMS systems, before SAP decided to move to them? Right, there wasn't any DBMS product that was younger than 10 years.
Can you replace your any-kind-of-application OLTP/OLAP/STREAMS database today with HANA and not change a bit?
Nope. Of course not.
Can you build extremely high performing reporting and data analysis scenarios with it that can barely be build with other systems? Absolutely.
So, instead of taking more or less arbitrary database tasks, I highly suggest to actually try to build something with HANA if you want to learn how it works.
I'm surely not a sales guy myself - but I don't fancy this f.u.d. approach of "objective" testing.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.