October 26, 2023 at 12:35 pm
Open a case with MSFT and send them the dumps to analyse whats going on.
Although this is worrying
2023-09-26 16:14:10.60 Server Timeout waiting for external dump process 17012.Looks like something is getting in the way of SQLDumper.exe, do you have anything like CrowdStrike, Bit9, CarbonBlack, McAfee etc etc loaded on the server also?
Unfortunatelly I don't have Microsoft account and I can not send this case to MFT.
Today is 26th and at 13:00 the same problem happened. All month database works fine untill today.
I don't have software like this "CrowdStrike, Bit9, CarbonBlack, McAfee"
Yesterday I disabled Eset Internet Security.
October 26, 2023 at 1:20 pm
Probably a dumb question, but is there anything interesting in the windows event logs apart from the "application" log? What I mean is, is there anything interesting under System or security or setup or application and service logs (the sub-items in there)?
I was following the same idea but there isn't in windows event logs any other problems connecting this this main one in the same time.
Also, is there a reason you are turning off auto-close and changing page verify to checksum all the time like that? That feels like it should be a "set once" type operation, not a "repeated operation" to me...
This scenario making our main company warehouse database software which use SQL Server when it's making auto backup every few hours.
Plus, anything in the windows task scheduler that MAY be causing issues?
If you can clone this system and isolate it, I would be interested to hear if you can force the problem to reoccur on the test environment by doing things like: A- run all WINDOWS scheduled tasks that are scheduled to run around when this is failing B- run all SQL scheduled tasks that are scheduled to run around when this is failing (looks like backups?) C- run a scan with your antivirus/anti-malware against the cloned system with the same settings as live
I made many hardware and software verifications until today. All do not get any idea about this problem source. Today problem happened again 26th at 13 oclock. The same as before every month.
Another advantage to cloning and isolating it to a new VM (if possible) is that you will be able to rule out 3rd party applications like SQL Monitor (not sure what other 3rd party tools you have). MAY be able to use the clone to narrow down what 3rd party tool is causing the issue (if it is a 3rd party tool).
How to move actual hardware machine to Virtual One? I never made this before
October 26, 2023 at 2:19 pm
Moving physical hardware to virtual is easy in something like VMWare using a process called P2V. It stands for "Physical to Virtual" and it is for moving physical hardware to virtual environment. Downsides are that this process usually will deactivate the windows license on the physical and remove the physical machine from the domain and it requires some downtime, but once the process is complete, the virtual machine should function the same as the physical one with the added benefits that come from virtual machines (easy cloning, easy migration to new hardware, easy snapshots and backups, usually faster reboots, etc).
But I wouldn't test doing a P2V on that machine until you are sure that it will succeed when P2V'ed as if it fails, I wouldn't want the machine offline. So my first step would be to build up a machine with near-identical hardware and software but on an isolated network to prevent accidental access. Then leave that system running for a month and see if it has the same error log entries. With the machine being on an isolated network, you should be able to rule out external actors on the machine. Plus if you have it on a fully isolated network, you can manually set the time to October 26th at 12:50 PM and then wait for 1300 to hit and see if the services crash. If they do not crash, that would lead me to believe the cause of the crashes is external to your machine and some other machine is causing the crash. If it does still crash, I would look at the services on the machine and scheduled tasks and try to disable any that are not machine critical and repeat the test.
Now if it doesn't crash it doesn't mean with 100% certainty that it is caused by external actors, just means that it is more likely. What I mean here is if the application that is causing the crash has some other trigger than the windows task scheduler, then setting it to that date and time may not do anything. It COULD be that the application causing the issue has its own internal triggering mechanism, but in that case you can probably find a suspect service and lock that down.
Now, on a slightly different note, I have a strong suspicion that after you disabled the antivirus (ESET), you won't have this problem again. I wouldn't recommend disabling the antivirus long term though. I would recommend configuring the AV to not scan your SQL files.
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.
October 26, 2023 at 2:38 pm
Also, I could be mistaken, but I am fairly confident that SQL Express handles up to 10 GB Databases, not 1 GB... and quick google confirmed this: https://learn.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2019?view=sql-server-ver16
I had a quick look through the thread and could not find a response to this.
I agree with Brian on this point – you have 10GB as the limit, not 1GB.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
October 26, 2023 at 3:57 pm
We have version SQL Server Standard 2019 so there isn't limitation of database size 10GB as for Express version.
Because we have 2 companies we use exactly 2 the same servers Dell Workstation T7910 with exactly the same hardware and software.
Configuration of all software is the same.
Company 1 - use SQL Server Standard 2019 because databese have size about 10GB
Company 2 - use SQL Server Express 2019 because databese have size 4GB
There is no problem with server company 2. Problem is with SQL Server Standard 2019.
ESET have disabled scanning all SQL Server folders
I will read more about VMWare and P2V - thank you.
October 26, 2023 at 4:11 pm
second page
October 26, 2023 at 4:29 pm
Few minutes ago databese create dump only few minutes after server reboot. Only one user on database - me. So it can't be other tasks. It can be only some problem with SQL Server Standard 2019 or warehouse software only whihc is only one software which have database on our SQL Server.
October 26, 2023 at 4:45 pm
I can pretty much guarantee that this is not a SQL problem, but a "you problem."
The comparison of the other company is interesting and I don't think was mentioned before.
The two companies are not the same, there is a sizeable difference, one is on express edition and one the other is on standard.
Something curious to me - did you reduce the max degree of parallelism to 1 on the standard edition instance?
October 26, 2023 at 5:51 pm
I am not sure how you ruled out "other tasks". SQL creating a dump is caused by something and the original dump you indicated to me REALLY looks like it is having troubles writing to the disk. I am not sure how you ruled out other software on the machine, the OS itself, or hardware failure? Just because you rebooted and you are the only user you are aware of on the machine, doesn't mean that the issue is caused by SQL or the software you are running. It could be you are running an older version and need some patches to SQL and the OS that will fix the issue. It could be the start of hardware failure (RAM, CPU, motherboard, or disk) and the bits that are bad are currently only impacting running software and not the OS. It could be a hacker got into your system and is causing it to crash so that they can get more memory for cryptomining.
It may be time to bring in the professionals - nobody on this forum can see your server and are just guessing based on what you tell us. Just because something looks innocent to you in the windows event log, it could be a huge red flag to someone else. Or you could have some service running that looks innocent but actually conflicts with SQL server so it should be disabled. I would reach out to someone who can access your server either physically or remotely for support. The software vendor for who you purchased your SQL Server Standard license from is a good starting point. Reach out to them and they should be able to get you in contact with someone from Microsoft for support if you don't have your own account with Microsoft. Or even just go on the Microsoft website and request support. You have a license to the tool which comes with support, so I would use it.
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.
November 29, 2023 at 12:43 am
I changed this max degree of parallelism to 1 today because this Non-yielding Scheduler error still happen every 30 days. Before vale of max degree of parallelism was set 15 (default value made by installer). On this computer are 2CPU's and 72 cores.
December 6, 2023 at 2:57 pm
This was removed by the editor as SPAM
December 7, 2023 at 6:41 am
Users told me that they can not connect and after some time database work fine for next few minutes. Best solution is restart PC ... but next month the same problem happen. My hard discs are fine (SSD NVME), Windows 11 PRO and SQL Standard 2019 have latest updates. I don't have idea what to check and what to do next.
That's what the OP had in his original post. This looks like a prelude to spam.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2023 at 2:00 pm
To add to what Jeff said, there are a lot of things mentioned in this thread to check. If it is a scheduled "crash" of the instance, then you likely have some scheduled task in place on either the SQL side or the OS side.
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.
December 17, 2023 at 12:51 pm
This was removed by the editor as SPAM
Viewing 14 posts - 16 through 28 (of 28 total)
You must be logged in to reply to this topic. Login to reply