Oh my God, I was scratching my head for the past twenty minutes trying to figure out how these scripts work. Thank you for that lovely explanation. I feel more confident now using OLA scripts for my enterprise database :)
For companies that have small budgets, for managers that need to get people trained with no training budget, and those of us that have no formal DBA training that learn from hands on experience we all Thank you and Ola.
You just made my day kind sir! Feel free to request a "basics" video and I'll see what I can do. Ideally something that affects lots of people, or a concept that needs to be explained in less "DBA" language.
Thank you Kevin Hill, Jim said it all. We often have no training and you are the source of explaining what we should do next with Ola's script. Thanks to both of you !
Things to note... the job setup is cool (I also use Ola). I recommend changing the way the job reads its parameters to using powershell and running the stored procedures inside the DBAdmin database (because that's all this really is is a lovely script of sprocs). You can also develop to set retention time from hours to days if you'd prefer. This works best for keeping 0 retention. If you ever have any Ola questions, feel free to ask.
Like, running your indexing ola jobs after your backup ola jobs? You could chain it I suppose. Chaining can be bad if there's a failure in between (though you could code past that). I'd really recommend just sticking to some schedule. Just my two cents.
Ola scripts create their own log files when they run...easiest is to check that. If there is corruption reported, the job will show as failed. You should be alerting on failed jobs, so you will know right away. Also turn on alerts for errors 823/824/825
If you mean the stored procedures that run the backups, index maintenance, etc. they are installed in whatever database you specify when you run the MaintenanceSolution.sql file. by default, that is master...but please make a different DB for this.
Each job takes a database parameter, where you can specify a group such as "all_databases", or in groups. Check this link from Ola: ola.hallengren.com/sql-server-backup.html
You have a 'USER_DATABASES', 'SYSTEM_DATABASES', and then you can actually specify specific databases instead 'DB_1, DB_2, DB_4'. You can even exclude (say you want all user databases but DB_3) '-DB_3'.
Oh my God, I was scratching my head for the past twenty minutes trying to figure out how these scripts work. Thank you for that lovely explanation. I feel more confident now using OLA scripts for my enterprise database :)
Glad it helped!
For companies that have small budgets, for managers that need to get people trained with no training budget, and those of us that have no formal DBA training that learn from hands on experience we all Thank you and Ola.
You just made my day kind sir! Feel free to request a "basics" video and I'll see what I can do. Ideally something that affects lots of people, or a concept that needs to be explained in less "DBA" language.
Thank you Kevin Hill, Jim said it all. We often have no training and you are the source of explaining what we should do next with Ola's script. Thanks to both of you !
Thanks Kevin for putting this together. Very straightforward and loaded with value.
Thanks! been looking at the scrips and figuring out how to get started. This does help a bunch!
Excellent guide to help me getting started with the scripts! Thanks.
Things to note... the job setup is cool (I also use Ola). I recommend changing the way the job reads its parameters to using powershell and running the stored procedures inside the DBAdmin database (because that's all this really is is a lovely script of sprocs). You can also develop to set retention time from hours to days if you'd prefer. This works best for keeping 0 retention. If you ever have any Ola questions, feel free to ask.
Thanks William...but lets remember this is a beginner level video to get folks started that may not be DBAs.
@@Kevin3NF For sure! I'm just throwing out next level ideas; and offering any help if needed. :)
Very nice! Would you consider a follow-on about creating a maintenance plan to chain multiple (Ola) agent jobs in a recommended sequence?
Like, running your indexing ola jobs after your backup ola jobs? You could chain it I suppose. Chaining can be bad if there's a failure in between (though you could code past that). I'd really recommend just sticking to some schedule. Just my two cents.
Hi
Could we check the output of database integrity for user databases in log file. For ex: dbcc checkdb output
Ola scripts create their own log files when they run...easiest is to check that. If there is corruption reported, the job will show as failed. You should be alerting on failed jobs, so you will know right away. Also turn on alerts for errors 823/824/825
if i need to go and change the ola file, where i can find it?
If you mean the stored procedures that run the backups, index maintenance, etc. they are installed in whatever database you specify when you run the MaintenanceSolution.sql file. by default, that is master...but please make a different DB for this.
How can you specify which database will be affected by the script and where do you specify it ?
Each job takes a database parameter, where you can specify a group such as "all_databases", or in groups. Check this link from Ola: ola.hallengren.com/sql-server-backup.html
You have a 'USER_DATABASES', 'SYSTEM_DATABASES', and then you can actually specify specific databases instead 'DB_1, DB_2, DB_4'. You can even exclude (say you want all user databases but DB_3) '-DB_3'.
Hi ,
I wanted to exclude particular 'X' database how can I find 'DB_1' ,is my particular database relates ?Please help me out..
awesome information!
How to set the parameters for these scripts
That will depend on your organizational goals, workload performance, etc. Start with the defaults and adjust as needed
very good!
Subscribed
Dude... automate that SQL Server Installation with Powershell. Come on! ;)