I want to change my tables into InMemory table, and also I created SSAS from that table.
wheather OLAP could be faster if I change into InMemory tables ?
Please advice.
I am concern about my memory.
I am using SQL 2014 and SSAS Tabular
Thanks
If your SSAS is not in DirectQuery mode, I don't think it will get any faster since when processed it creates a copy of the data in the table.
I also don't think the processing will get any faster if you are selecting de whole table into a SSAS tabular table.
Anyway, the best approach here it's to test before/after in your Test enviroment.
Related
Is it correct in my understanding that we can build SSAS cubes sourcing from the transaction Systems? I meant the not the live but copy of the Live.
I'm trying to see if there is any scope to address few reporting needs without the need to build a traditional Data Warehouse and then build cubes on top of the data warehouse, instead build cubes to do Financial monthly aggregated reporting needs sourcing from backup copy of the Transaction systems.
Alternatively, if you have any better way to proceed please suggest.
Regards,
KK
You can create a set of views on top of you transactional system tables and then build your SSAS cubes ontop of those views. This would be less effort than creating a fully fledged datawarehouse.
I am a data warehouse developer (and therefore believe in cubes), but not every reporting solution warrants the cost of building a cube. If your short to medium term reporting requirements are fixed and you don't have users requiring data to be sliced differently each week, then a series of fixed reports may suffice.
You can create a series of SQL Server Reporting Services reports (or extract to Excel) either directly against your copied transactional data, or against a series of summarised tables that are created periodically. If you decide to utilise a series of pre-formatted reporting tables, try to create tables that cover multiple similar reports (rather than 1 monthly report table = 1 report) for ease of ongoing maintenance.
There are many other important aspects to this that you may need to consider first. Like how busy is the transaction system, what is the size of the data, concurrency and availability issues etc.
It is absolutely fine to have a copy of your live data and then build a report on the top of it. Bear in mind that the data you see in the report will not be the latest and there will be a latency factor depending on the frequency of your data pull.
I develop some application that has database wery generic so really can't use it for reporting. So I need solution how to create reporting. I'm developer so my knowledge in DBA domain is bounded. For now I have ideo to create another database where I'll pu denormalized data from original db. So I saw that I could use SSIS for that and woul be glad if someone could give me some advice how to attack that problem. Should I sync data once a day and run reports that way. Is there solution to sync data allways so reports would be up to date? Please any advice.. Thanks!
Damir,
What I get from your message is that you are getting close to build a Datawarehouse using a Star Schema pattern.
You could have two databases, One with normalized data and the other one with the Star Schema pattern (Your DW), and then create a script that would use your normalized data and put them in your datawarehouse. For the frequency of your script it is up to you : After each transaction, every hour, once a day, etc...
The advantage of having a datawarehouse is that you will be able to use OLAP cubes and the MDX language for your reports. It's a plus !
Hope it could help,
If you are on sql server 2005 or greater, explore Merge statement.
For smaller tables, just truncate and reload. 'Smaller' could be subjective - but if takes less than 2-3 minutes to load, that could be termed as small. Obviously, during that period any query that uses such tables would fail.
This fairly unusual, but because of office politics etc. we have (read-only) access to the data warehouse, but not to the live data. However we need up-to-date data to populate our relational (OLTP) database (MS SQL server. The data in the warehouse (also MS) is in star schema format (i.e. Dimensions and Facts). I am not very familiar with warehouse DBs. How can I get data from the warehouse into a relational database? My google-fu was too weak to get me any answers (lots for the other way round).
Thanks
Chavoux
If there is a data-warehouse, then the ETL process is already in place. So, use the same tool (SSIS ?) that loads the DW to extract data from the DW and move it to a different DB. You can probably ask your ETL guy to help too :).
SSIS packages? Anything that can load and transform data.
Sounds like the data warehouse is a SQL Server database so standard SQL can be used. You can use SSIS to transform the data from the DW and load it to the OLTP database.
I wan't sure how to word this question so I'll try and explain. I have a third-party database on SQL Server 2005. I have another SQL Server 2008, which I want to "publish" some of the data in the third-party database too. This database I shall then use as the back-end for a portal and reporting services - it shall be the data warehouse.
On the destination server I want store the data in different table structures to that in the third-party db. Some tables I want to denormalize and there are lots of columns that aren't necessary. I'll also need to add additional fields to some of the tables which I'll need to update based on data stored in the same rows. For example, there are varchar fields that contain info I'll want to populate other columns with. All of this should cleanse the data and make it easier to report on.
I can write the query(s) to get all the info I want in a particular destination table. However, I want to be able to keep it up-to-date with the source on the other server. It doesn't have to be updated immediately (although that would be good) but I'd like for it be updated perhaps every 10 minutes. There are 100's of thousands of rows of data but the changes to the data and addition of new rows etc. isn't huge.
I've had a look around but I'm still not sure the best way to achieve this. As far as I can tell replication won't do what I need. I could manually write the t-sql to do the updates perhaps using the Merge statement and then schedule it as a job with sql server agent. I've also been having a look at SSIS and that looks to be geared at the ETL kind of thing.
I'm just not sure what to use to achieve this and I was hoping to get some advice on how one should go about doing this kind-of thing? Any suggestions would be greatly appreciated.
For that tables whose schemas/realtions are not changing, I would still strongly recommend Replication.
For the tables whose data and/or relations are changing significantly, then I would recommend that you develop a Service Broker implementation to handle that. The hi-level approach with service broker (SB) is:
Table-->Trigger-->SB.Service >====> SB.Queue-->StoredProc(activated)-->Table(s)
I would not recommend SSIS for this, unless you wanted to go to something like dialy exports/imports. It's fine for that kind of thing, but IMHO far too kludgey and cumbersome for either continuous or short-period incremental data distribution.
Nick, I have gone the SSIS route myself. I have jobs that run every 15 minutes that are based in SSIS and do the exact thing you are trying to do. We have a huge relational database and then we wanted to do complicated reporting on top of it using a product called Tableau. We quickly discovered that our relational model wasn't really so hot for that so I built a cube over it with SSAS and that cube is updated and processed every 15 minutes.
Yes SSIS does give the aura of being mainly for straight ETL jobs but I have found that it can be used for simple quick jobs like this as well.
I think, staging and partitioning will be too much for your case. I am implementing the same thing in SSIS now but with a frequency of 1 hour as I need to give some time for support activities. I am sure that using SSIS is a good way of doing it.
During the design, I had thought of another way to achieve custom replication, by customizing the Change Data Capture (CDC) process. This way you can get near real time replication, but is a tricky thing.
I'm trying to configure storage mode ROLAP for a partition in an existing SSAS cube. The cube is a little messy in that the measure group is defined by a named query (as opposed to a table) and the dimensions are defined in several different data source views (DSV).
This is the error message I get when querying the cube with mdx:
Executing the query ...
Server: The operation has been cancelled.
Errors in the high-level relational engine. The 'dbo_dim_account' table that is required for a join cannot be reached based on the relationships in the data source view.
Execution complete
Note that MOLAP storage mode with proactive caching works fine. This problem occurs only when storage mode is ROLAP or HOLAP.
Also, I have tried to add the tables of all dimensions to the DSV of the cube in question but that doesn't seem to help.
Any ideas?
Not an expert here, but you could try importing the AS DB in Visual Studio.NET - "Import Analysis Services database" in the New Project... dialog.
Once in there, you can see the table schemas for the Data Source View (which is where the relational tables are defined that the cubes are extracted from). Next, look to make sure the "dbo_dim_account" table is there and that your fact table is related to it.
It may be that a dimension and fact have to be in the same DSV for the relation to work?
Also, maybe the SSAS flight recorder or Application log would have more issues?