That means PHXDiag wasn’t able to connect to your SQL Server. It might be a firewall issue, or it might be that the server & instance name wasn’t quite typed in correctly. For complex server names (like with periods, backslashes, tricky characters, etc.) make sure to frame the server name in quotes, like this:
PHXDiag.exe --datasource "MyServerName\MyInstanceName"And same with your username, password, and database name if necessary.
It probably means we were able to connect to the SQL Server, but your login credentials weren’t accepted. If you’re using SQL authentication with a password that contains symbols, try enclosing the password in double quotes.
That’s okay. It means that one of the diagnostic queries couldn’t complete within the default of five minutes. You can change the timeouts if you like.
That’s okay – it means you’re using Azure SQL DB, which doesn’t support some advanced diagnostic tooling available in SQL Server and Managed Instances. We can still get plenty of diagnostic data without that, though.
That’s okay – it’s a known issue when Excel tries to open a file with complex cell contents. Since PHXDiag is taking your queries and putting them straight into Excel, it’s entirely possible that some of your queries will give Excel problems when opening the file.
You can just say yes, open the file anyway, and Excel will prompt you to delete the discarded contents. That’s completely okay – the spreadsheet is still chock full of diagnostic goodness.
By default, we don’t analyze indexes on servers with hundreds of table partitions because it can be pretty slow going. If you’re sure you want to run the analysis, you’ll need to make two changes:
Contact PhoenixDBAs for an updated version.