1
votes

We are using a SQL Server Tabular model which we use for self-service BI purposes. At monthly basis we have some 90 distinct persons who are using the model. Recently we encountered some issues/errors in the client tools(Excel and Power BI) that are connecting to the Tabular model. See screenshots. We did not make any significant changes to the model the past period. We noticed that the errors keep showing up after our incremental load, i.e. a full process of a number of partitions we process these partitions every 15 minutes. The process is kicked of by a SSIS job which is scheduled every 15 minutes and processes 5 partitions in 3 tables.

Edit: After some research I figured out that the problem lies in the perspectives. Everytime I do a full process on any object. The error appears. This does not happen on the default model view. Still not found a solution though.

The error occurs when you make a change to the power bi report or the excel file. For example when you do a refresh, or when you click a filter. If you press refresh multiple times the connection comes back and everything works as it is supposed to. It seems like the clients lose their connection to the model. After 15 minutes the problem occurs again.

This is very aggravating for the users. Especially when they are in the middle of a presentation.

This is what we tried:

  • We tried searching Google for a solution
  • Checked that we have the latest SQL Server 2016 update (13.0.5149.0)
  • SSAS Builds from Visual Studio(2015 en 2017)
  • No full process on tables, only on partitions.
  • Upgrading the server from 4 to 8 cpu cores.

I hope somebody can help us.

Screenshot Power BI

Screenshot Excel

3

3 Answers

1
votes

You shouldn't have the error that you are seeing with just a full process of a partition or even the full table. We do this every hour for a number of core tables and we do not see any issues like this (and we would)

I am starting from the hypothesis that

  • Your 15 minute process is doing more than just processing the partitions with a refresh command
  • Something else is happening on the environment (either scheduled or not). Who has permissions to change the schema? Could it be users / developers deliberately or not making changes?

The only things that should cause that kind of error would be Alter, Delete or CreateOrReplace TMSL commands

So unless that triggers your own ideas on a diagnostic process I would do the following steps

Note: I presume that your users also see this issue on your test environment when you run your 15 min processing routine on that. You should do the following on that test environment where nothing else is running to eliminate the possibility of someone else interfering with the experiment. If you don't have a representative test environment then you will have to do on live but I would do this out of hours or under some kind of change control process with your 15 minute refresh turned off and admin permissions to the cube heavily locked down to ensure that nothing can interfere with your experiment.

First prove that you can reproduce this issue with the 15 minute routine

  • Get your sample PowerBI report that is known to present the error (I'd prefer Power BI for a repro as it is slightly simpler than Excel)
  • Refresh your PowerBI and explore the data to prove that the error doesn't occur
  • Run your 15 minute process
  • You should now see the problem reported. If you do, great, you have a reproduceable issue! If you don't then it is not quite as you thought it was and you need to find the way of reliably reproducing these errors. (perhaps something else is happening that isn't the 15 minute process)

So now you are sure how you can reproduce the issue, you need to isolate whether it is really the processing that is causing the problem

  • Refresh your PowerBI and explore the data to prove that the error doesn't occur
  • Execute (via SSMS) your XMLA that processes the entire database for one of your tables

it should look something like this

{  
  "refresh": {  
    "type": "full",  
    "objects": [  
      {  
        "database": "yourdbname"  
      }  
    ]  
  }  
}  
  • Do the thing that your users do when they see the issue.
  • If you too see the issue, then I would raise to Microsoft Support as this shouldn't happen
  • If you don't see the issue then you can refine this processing to just be the partition for a single table. But as we have done a process for the entire db above if shouldn't change the result
  • If you still don't see the issue then it isn't the processing that is causing this issue (which I suspect) and it is something else in the 15 minute routine that is causing it. Look deeper into that process and understand what else it is doing.

Alongside this checking the logs should show if there are any other processing tasks or types of XMLA happening.

I hope these ideas get you closer to finding the actual activity that is causing this experience for your users. It would be great if you could post with how you got on and what you found.

0
votes

I have the same problem here if I install the latest CU on my SQL Server 2017. My production environment is still running with CU3 (Jan/2018) due to this problem.

Knowing that I would suggest reverting your installation to a previous release. Maybe 13.0.5026.0 (SP2) or even to the 13.0.4466.4 (Jan/2018).

0
votes

I am facing the same issue with SQL Server 2017 CU 11 installed. The issue indeed occurs in case of a 'full refresh' in combination with the use of a 'perspective' in an existing connection. The workaround to use the default 'Model' in the connection does indeed 'solve' the issue.