Viewing 15 posts - 7,876 through 7,890 (of 59,091 total)
Teaching a man to fish...
If we use almost the exact words from your post, do the following Google-Search.
approx memory required for in memory tables
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2020 at 10:55 pm
There's another strong and unavoidable issue with TempDB. They've made it so that it follows the same rules as if you invoked Trace Flag 1117 (equal file growth of all...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2020 at 6:29 pm
I don't necessarily consider myself a complete [expert] in SQL Server, but that feeling isn't based on any inferiority complex, because I actually don't believe most self...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2020 at 6:22 pm
I agree with the others on this, especially Scott. It reports a problem with the time being formatted incorrectly whether or not it includes the date or not. But, going...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2020 at 4:21 pm
I'm thinking that SEQUENCE is going to be about 4 times slower. That's just a guess.
Sounds crazy but this is fascinating to me because I work with some really large...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2020 at 4:04 pm
BAAA-HAAAA!!! Step 1 is to ask them how to get the current date and time in T-SQL. 😀
Of course, when you do find an expert, can you actually use them...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2020 at 2:20 am
No. I'm NOT recommending that you set a MB value the same as the MDF/NDF for LDF although they can be set the same. "It Depends". On what?
The LDF file...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2020 at 12:36 am
Thanks everyone. I have added a clustered primary key in our test environment but can't compare the performance as the configuration is totally different. When I do the 300...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2020 at 12:33 am
This is really the same as a "Catch-All" query. Why not write the dynamic SQL to do it?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 11:05 pm
It's all in that link: https://www.brentozar.com/pastetheplan/?id=SJF21m0lU
INSERT INTO @retTable
SELECT c.ClaimID, cd.ServiceCode, c.ServiceDate, cd.ServiceQty, c.CareProviderID, ISNULL(cd.DiagnosticCode, c.DiagnosticCode), c.SpecialtyCode AS Speciality,
sg.GroupCategory AS ServiceCodeGroupCategory, 0, NULL
FROM...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 11:00 pm
I think something like this is what you're looking for...
SELECT *
FROM sys.dm_db_index_usage_stats x
JOIN VendorDB.sys.indexes i
...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 10:53 pm
sys.dm_db_index_usage_stats covers all of the databases no matter which database you call it from. You have to identify the database_id in your query.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 10:49 pm
Hmm, maybe I misunderstand, I thought the OP said that it was just that one query for the max date, ~ every hour, in order to provide that...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 9:19 pm
As a bit of a sidebar, why not just use the Developer's Edition for evals? So long as you never use the Developers Edition for production, it's legal.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 9:09 pm
Yes, because MONEY is a precise data type with 4 decimal places. It's implemented as a 64-bit integer, scaled down by 10000. That and DATETIME must be the two...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 7:30 pm
Viewing 15 posts - 7,876 through 7,890 (of 59,091 total)