I know that feeling. I come here to learn too and help where I can.
I am an accidental DBA as well.
I would give them a high estimate as it is tricky to say with any certainty (as far as I am aware). It can rely on a lot of different things like database activity, physical server activity, available RAM/CPU, available tempdb space, disk I/O, etc.
Do you have a test instance of this database? If so, you could try running it against that and estimate based on the hardware differences. In my case, live runs about 3 times faster than test in most cases, but it depends on your systems.
Or you said you ran that command last week friday? How long did it take (roughly)? I believe the FULLSCAN option means it should take just as long to run it 2 times with a 5 minute wait inbetween or with a 5 week wait inbetween (presuming minimal data changes) so I'd expect it to be roughly the same time.
I just kicked off the run and I'm heading home. I'll check it tomorrow in the morning when I get here. As you said, it's already Tango Uniform so there's little to lose at this point really and the MS Engineer DID recommend looking at the statistics. We'll see...
Thanks again sir (or ma'am) as the case may be.
No problem. It won't make things any worse updating the statistics it just might not help.
But what I've often found when working with any support guys is that unless you do exactly what they ask, they likely won't help you much further. I imagine the support guy you are working with either ran some commands to see the stats were out of date and needed updating, knows more about your system and thinks updating stats will help OR has a script of things they tell people:
1 - update statistics
2 - defragment indexes
3 - reboot
(note - those are not my suggestions, just an example). Something I'd be curuios about is if it was SQL being grumpy or sharepoint being grumpy? Hopefully the updated stats help, but I wouldn't be surprised if this is more of a temporary fix to a larger problem (memory pressure, CPU pressure, insufficient resource allocation, etc).
SQL is the problem as my Regate SQL Monitor installation helped pinpoint the issue to a recurring query against the AllUserData table of a particular SharePoint content table. This query throws blocking process and long running query alerts nearly perpetually - all on this and the Workflow tables which are joined (and rejoined 3 times in the case of the AllUserData table) in one massive parameterized query. So the trouble lies in there somewhere as I see it. The MS engineer also wanted the SP skin to check the Max Degrees of Parallelism setting which could be it as well.
Tomorrow's another day and the good thing is I'm pushing my own knowledge base!
What version of redgate SQL Monitor are you on? Is it 7.0.0 or 7.0.1? If so, you may want to upgrade to 7.0.2. Redgate SQL Monitor 7.0.0 has a bug in it that killed performance on our SQL databases to the point where queries that should take less than a second were taking hours to complete and it required a restart of the SQL Instance to fix.
If it is version 6 or lower, then this likely isn't your issue or if it is version 7.0.2 then you shoudl be fine as well.
V5, I believe. I'll double check tomorrow but I'm pretty sure it's 5.
Some of the changes in 6 are a bit annoying especially if you have some form of failover set up... it detects SQL instances differently than 5. 7 is nice though with the reporting built in. The email report schedules are a bit laggy but they are fixing that in 7.0.3 (or so I am told).
But heres hoping that the stats update helps. Keep us posted
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.