A Fix To PolyBase Issue In SQL Server 2019 Developer Edition

Usually, we install SQL Server by default, it works just fine. However, sometimes, we might face some problems in the new version installation. I got an issue when I installed the SQL Server Developer Edition 2019, that is related to a PolyBase issue.  This article will introduce the problem, the reason and the fix. (SQL Server 2019 Developer Edition Installation see here)


Once in 2020, after I installed an instance of SQL Server 2019 Developer Edition, I found my machine hard disk was eaten very fast. The following is what I met this situation again early this year, one can see the hard disk reduced close to 100 GB in just one day. 


I am not SQL Server database administrator, I do not want to debug it, and I do not care about the real reason, I just want to have a fix on it. By online searching, I found the solution from one excellent article, in which one can get the real reason and debugging process, what I will introduce here is just the conclusion.

The problem is caused by, in our installation, we installed this component: PolyBase

and configure it like this:

I do not know what this component is for, and the installation is successfully completed:

However, there is an issue with this component.  If we open service, we can see that the PolyBase components are always in the starting status, which means they always cannot be started:

The issue is caused by that these components need to connect to SQL Server by TCP provider, however, the TCP/IP as a network protocol for SQL server is unable by default.  This can be seen by opening the Computer Management: 

Therefore, the SQL server will report this problem automatically in log file, about every half an hour making a dump file that is about 400 MB, which will eat the hard disk 20~30 GB every day.


Simply make the SQL Server TCP/IP protocol enabled like this


After restarting the SQL Server and the PolyBase service, you will see the PolyBase components are running. 

Then there will be no more garbage dump files created in the SQL Server log folder. And, you probably need to manually delete the previous dump files to get the lost space back.


This bug is fixed and the main idea is from the article below in reference, thanks a lot for the Author. If anyone has an interest in the technical details for this issue, you can read this article.