Restore command is hanging after logged as success
Oleksandr-Kushchak-i2 opened this issue · 2 comments
I have noticed that the sqlcmd command is hanging on the restore, although accoridng to the logs (on both server and the client containers) the restore is complete.
RESTORE DATABASE successfully processed 58496 pages in 1.332 seconds (343.088 MB/sec).
After the above message is logged, sqlcmd is still running for 10min or longer depending on the machine paramaters.
I have followed documentaion for restore and still seeing the same issue, is that expected?
After further investigation it seems to me that the database is fully restored and operational after the message is logged, so I'm not sure what exactly is it doing and how to stop it.
Waiting this long for restoring a tiny database is not what we expected and we are looking for a solution. Any insight would appriciated.
I had the same issue - it's like the command never says it's done. Doing an exec to shell and killing the restore process would continue and the database would work fine.
I found using the mssql-tools version 18 resolves the issue and tweaked my dockerfile.
`FROM mcr.microsoft.com/mssql/server:2022-latest
USER root
RUN apt-get update &&
ACCEPT_EULA=Y apt-get install mssql-tools18 unixodbc-dev -y
USER mssql`
The sqlcmd path for tools 18 is /opt/mssql-tools18/bin/sqlcmd
And you'll most likely need to pass -C to your sqlcmd to use 'Trust Server Certificate'.
@ZacUSNYR thank you for sharing this, I can confirm that using mssql-tools version 18 resolves the issue. Many thanks!