You should analyse and determine the cause of the Stack dumps, If you have support from microsoft, you can consult them and of course you can always delete them, they are nothing but memory dumps, may be generated because of memory issue, access violations, DB courruption, etc. You can also check SQL Server error log for the information or errors logged at the same time when dump was generated. Sometimes dumps are also generated because of Database corruption, So i will also suggest to run DBCC CHECKDB.
Hope this will help you, Thanks.
If you are running the GUI on the same machine as the mssql-server service, then you can use localhost for the address (127.0.0.1). If you are running the GUI from a different workstation, you'll need the IPv4 address of the machine where the mssql-server service is running. You can obtain that by running ifconfig
from a Linux terminal prompt. Sample output from ifconfig
:
eth0: flags=4163 mtu 1500
ether 00:15:5d:89:45:01 txqueuelen 1000 (Ethernet)
RX packets 423 bytes 137827 (134.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=4163 mtu 1500
inet 192.168.200.11 netmask 255.255.255.0 broadcast 192.168.200.255
inet6 fe80::2f70:9d15:8e7d:16cb prefixlen 64 scopeid 0x20
ether 00:15:5d:89:45:04 txqueuelen 1000 (Ethernet)
RX packets 20138 bytes 2006000 (1.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 19756 bytes 30125657 (28.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1 (Local Loopback)
RX packets 3239 bytes 361340 (352.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3239 bytes 361340 (352.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
In the output above, the bit that is important is the "inet" address, which in my case is 192.168.200.11.
The default port for SQL Server is 1433 - unless you chose a different port in mssql-conf use that port number. Ensure the firewall on the Linux box is allowing outside connections via 1433, if you intend to connect to SQL Server via the network.
Use sa
as the login, and the password you specified during SQL Server setup via the sudo /opt/mssql/bin/mssql-conf setup
command.
I would leave the domain and unix socket path blank.
Once you have connected to the instance, you may want to configure a non-sa account. Do that with the CREATE LOGIN
statement.
Just an FYI, you can use SQL Server Management Studio to connect to SQL Server on Linux, if that's your desire. Alternately, you can download Microsoft's native GUI client for Linux (and Windows & Mac), Azure Data Studio, here.
Best Answer
So it turns out these are packed archive. It's part of the "Platform Abstraction Layer" that hosts the operating system in a library, or "Drawbridge" Library OS. Not much is known about Drawbridge yet, but here is one resource on Github that pointed me over to a tool
sfpack
.sfpack
was able to extract these archives.