At least these "presentations" many times make people feel shame, I'm guessing those stick with them, so you are kind of using the teaching method already 🤔. And give the rest of us a few chuckles along the way 😁
As someone who started out as an Oracle DBA (15 years) and got a later job as an SQL Server DBA (now I do both), it's really one-way. The benefit of being an Oracle DBA is you learn TIGHT code (semicolons matter) and adherence to syntax (Microsoft plays fast and loose). The engines are completely different, however, and as Brent points out, they're only marginally comparable. For example, Views on Oracle are AWESOME. Not so much on SQL Server. Also REDO vs UNDO - HUGE difference! TOP vs ROWNUM. Transaction handling (explicit vs implicit COMMIT). And database nomenclature... but what's in a name? I'd hire an Oracle DBA into an SQL Server position, sure. I would be skeptical going the other way, however. To much to UNLEARN.
That’s a good assessment! I would say organisations like to keep you as a junior for as long as possible to pay as little as possible. Also correct when you define experience, I work with people who have more ‘experience’ than me, more qualifications than me but often come to me for advice, questions that often are very trivial and they should know better…
@@BrentOzarUnlimited Great to hear this! I'm coming from Data Engineering background, especially working in Azure and I want to expand my knowledge. Thanks for creating these videos.
There is in fact a performance benefit to using N'..' Unicode strings in WHERE clauses. I've seen many, many cases where comparing a Unicode column to a non-Unicode string (or even another non-Unicode column) causes SQL Server not to use the available index on the Unicode column.
@@BrentOzarUnlimited So my original reply was backwards. The problem occurs with VARCHAR columns and Unicode strings in WHERE clauses, where SQL Server decides to do an implicit_convert on the column to NVARCHAR instead of the constant to VARCHAR, thus reading every row and getting an index/table scan instead of an index seek. Sent some screenshots as requested.
@@brandonwiese4615right, you had it backwards. The scenario we discussed on the video, the N doesn’t matter, as I explained there. But glad you learned something about implicit conversions!
For the last question: jtds odbc is an pure java driver. I'd guess that the MS odbc driver is writte in C++. That might by the reason for the performance improvement.
Hey Brent for that last question there could be a "driver" difference in connection flags. I've had ARITHABORT cause significant slowness when set to false. Some of the drivers out there set it to false as a default, unlike what SSMS defaults, for instance. Thanks for what you do for us! Always learn something...
Ya, I was thinking of slow in the application, fast in ssms and going “the set options being different between the drivers would be the first thing I would check”
really really wish they’d put proper DAGs in standard - it’s the only think I really really long for in standard - company isn’t interested though lol - been a victim of my own success with mirroring and traditional trn/ bak files for HA and DR. Why pay a gazillion times more per core to make my life easier 😂
Just a note about q.1. The Statement "storage is cheap nowadays" may not work in the Azure world. For example, Microsoft charges ~30 USD per 1GB per month for Microsoft Dynamics ERP databases(that is based on SQL Azure), so some indexes may be quite expensive :)
If you wanting to use read scale AG with the intent of running reports off them then do choose AGs over log shipping - one of our clients tried log shipping and you have to choose to either give priority to applying the shipped logs (i.e. possibly cutting reports short) or give priority to running reports (potentially blocking the logs being applied when reports leave connections open). Read scale AGs solved this issue
That’s really interesting. I always assumed the differences were minor, aside from syntax and tooling. I’ve never spent any time learning DBA stuff anywhere other than SQL Server though.
It depends on what you're looking for and what you need your DBA to do imo. It also depends on if they understand there and differences and are willing to learn the differences between platforms.
That's a great question - for more details on that, check out our Fundamentals of Parameter Sniffing class: training.brentozar.com/courses/enrolled/1336969
Yes they are transferrabke. Most of the common things in query writing are the same. It's only in the interesting stuff that you find different syntax and commands.
ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-g6fqxTPnDd0.html: I have seen this happen when the proc contains a for loop that does a bunch of stuff for each row returned in a previous query. The painting of the execution plan takes forever and in some instances can blow out memory in SSMS. Imagine a loop that runs 5 queries and has to do this for 200 rows.
Wouldn't it be a good idea just to read the questions? TractorDBA just asked for a good resource. So one may expect that you do know people who are into security
