For question 1 – Cancelling or stopping the job after it is doing work will not roll back the work that has already been done, so there is no harm to stop it or kill the execution.
For question 2 – Keep in mind that online index rebuilds do still take some locks and there are limitations involved as to whether an online index can be performed. I would look here for a discussion of those limitations. I probably wouldn’t run this script during the day, even if you can get the online index rebuilds to happen. Index maintenance can be resource intensive.
For question 3 – Ola’s scripts aren’t going to do anything that is going to damage the database.
When I looked at your other question, I had to wonder whether the index maintenance routine is causing the log file growth.
You say, “Because of the problem with the log partition running full after every database update I’ve received a different script which where I can set Proportion of maximum indexes to be maintained per database. But I think this script is not as powerful as olas script, maybe because it doesn’t update statistics or doesn’t rebuild enough indexes? I’ve inserted a lot of new data recently and some querys are really slow since then and it’s up to the database.”
It seems to me that part of your complaint is things run slow after you update and change a large amount of data and people suggested updating the statistics. You could do that with a separate Ola job with T-SQL like the below, which is on his site.
@Databases = ‘USER_DATABASES’,
@FragmentationLow = NULL,
@FragmentationMedium = NULL,
@FragmentationHigh = NULL,
@UpdateStatistics = ‘ALL’