Voice of the DBA

Tag: Fabric

  • Is Fabric a Reliable Service or a Ripped Resource?

    Over the last few weeks, I’ve noticed a few complaints from different friends and customers about issues with Microsoft’s Fabric service. I had assumed these were isolated incidents in just a few places, and customers were being refunded according to an SLA. Then I saw Joey D’Antoni’s post this week about Fabric going down. It lists quite a few of the incidents in June, including a few global ones.

    However, the most surprising thing in the post was this link, noting Fabric doesn’t have a dedicated SLA. Instead, it’s under the general Microsoft support agreement, meaning your organization needs to have a support plan to get help. I think that makes some sense, but I’d really expect that a data service in the cloud, including an analytic service that touts itself as real-time, would have a high SLA. Some agreement on the order of 4 9s at least, if not 5.

    For those of you who think you can do better on premises, I’ll remind you that four 9s mean you get 52 minutes of downtime a year, or 1 minute a week (roughly). Five 9s is 5 minutes a year, and the weekly calculation doesn’t matter. I’ve had systems run for a year, but a lot, and not a lot of databases, especially with patching 6 times a year. This year, with AI (my guess) finding lots of holes and GDR releasing quite often, I would guess that three nines is out the window for most SQL Server systems that aren’t HA clustered in some way.

    As a point of reference, Denny notes that Azure SQL database, Business Critical, has a four-and-a-half 9s level of reliability and financial refunds for costs if that’s exceeded. You will need some sort of business insurance if you worry about revenue issues, but my guess is that most of us live with the downtime and work around it (and hopefully, plan for it).

    I’ve been skeptical of Fabric (outside of Power BI). It feels cobbled together, so many issues are reported, and I feel like it’s immature. If I were working on a new analytics project, and we didn’t have a solution, I might PoC it, but I’d be more likely to consider Databricks, Snowflake, or Redshift rather than Fabric.

    Perhaps you have a different view, or you have had success with Fabric. I know some people who have, but it seems one-sey two-sey and not commonplace. There seem to be so many workarounds and issues; it makes me skeptical that Fabric is really ready for primetime if Microsoft won’t stand behind it. Databricks only gives credit up to three 9s, but if they fall below 95%, they issue a 100% credit. Snowflake offers four 9s.

    I feel that if Microsoft were confident in their reliability, they’d offer refunds if they didn’t perform.

    Steve Jones

  • Database Mirroring is Back in Azure SQL Database

    Database mirroring was a cool feature in SQL Server 2005. I guess it’s still a feature, though it’s listed as deprecated in the documentation. There is still a mirroring dialog in the SSMS database properties dialog in more recent versions of SQL Server, but I don’t know if there is a good reason to use mirroring over Availability Groups.

    That’s why I was surprised to see a public preview announcement of Azure SQL Database Mirroring to Microsoft Fabric announcement. Apparently you can easily move Azure SQL Database data to Fabric and have it written to Delta Parquet tables in OneLake. No ETL, no need to do the data conversion yourself, or at least not much of an effort. I suspect you still need to understand this and do some configuration for how your Parquet files will get written.

    If you go through the documentation, it’s interesting (and annoying) to me that the docs keep saying replication. I hate when we’ve overloaded terms as mirroring and replication mean specific things in SQL Server, so I wish they would use some other term (copy, extract, ??) to describe what is happening.

    Whether this is useful to analytic workloads remains to be seen. I am curious what the people working with Fabric think of this feature. I wonder if this is useful, or if this might cause headaches or performance issues. Since this feature is in preview, I doubt anyone knows yet, but it will be interesting to see how this compares with Synapse Link and if it is more or less helpful.

    Moving data around for different purposes has always been a challenge. I know that some people might feel the costs involved in this aren’t worth it. I know a lot of technical people that would say “I could do that.” I have no idea what they costs are. but I know that a lot of people have spent a lot of hours managing ETL packages and adjusting them as schemas change and new requirements appear. I get the appeal of Synapse Link and this new Mirroring to Fabric features.

    I do wish this type of feature was more solidly built into the SQL Server instance. I suspect it will come at some point, and it’s being tested and baked in Azure first. However, I hope that if/when it comes, that the feature has good tooling and some polish to its operation. We’ve had too many features in SQL Server that are partially built, with limited tooling, and a lack of performance characteristics that many of us would desire.

    Steve Jones

  • Archive to the Lake

    Microsoft Fabric was announced at Build in May 2023. This is the next evolution of data warehousing from Microsoft, folding in Synapse and a number of other technologies to create a simpler location for storing and analyzing data. We’ve published some articles on the platform and there’s a great presentation from Mr. Paul Andrew on Linked In. It’s worth listening to, even in the background. Paul has a nice style and a great voice.

    Part of this platform is OneLake. This is a data lake for your org, just one of them, and while it’s able to store data in many formats, it’s mainly optimized to read tabular data in the delta parquet format. This is essentially a compressed text file that allows for some transactional changes to the original data in parquet format.

    I don’t do a lot of work with text files, and I’ve been suspicious of using lots of CSV or other text files in a warehouse environment, which is what a lot of people were advocating a few years ago. Exporting tables into lots of files split on some field, like date, while easy, didn’t seem like the best way to move data for reporting.

    Fabric, however, is optimized for reading delta files. A few presentations I’ve seen from people have advocated for exporting your data from SQL Server (or other platforms) into parquet. While I don’t know there’s a native way to do this (yet), I suspect one is coming. I’ve seen lots of articles (one, two, three, more) about how to do this now. We also have SQL Server able to read these files with external file formats already, so I’m sure we’ll have an easy way to write them soon.

    Many of us struggle with large systems, especially with query performance. We’d love to archive off data, though that’s often impractical. However, in an amazing, wonderful world, maybe we’ll get lots of people doing this, writing about it in the media, and our bosses will start to let us establish an archive in the lake. We could move some data there, especially old, unchanging data. We could delete that from source systems. We could have all our users happy.

    I don’t know if I see lots of data moving to the lake, but I certainly expect lots of it to be copied. If you haven’t thought about archives, data lakes, and text formats, it’s an area that seems to have a lot of growth. Perhaps it’s of interest to you and you might find a new career.

    Or maybe you just hope it gets widely adopted to relieve some pressure on your OLTP server.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.