This month’s invitation is from Jeff Mlakar and I really am looking forward to reading some of the entries.

If you’ve ever worked on a greenfield OOP project, you’ve probably felt like there is a lot of work investment up front that builds a base for your application. For a long time bit, it feels like very little is getting done as you build classes and subclasses, and experiment with the structures that make sense. Your users and managers may complain wonder about what work is actually being completed in this stage.

Eventually this tips over and all of a sudden you have something to show for your efforts and your objects start becoming useful and visible to others.

This is my story.

Early in my career, I learned to program using FoxPro. This served me well and let me build a number of useful applications for various clients and employers. Eventually I was hired to manage a tiny small IT department that had to maintain and existing FoxPro inventory and order entry system and the internal infrastructure, as well as manage a rewrite of this application to a more powerful, useful system.

Prior to my being brought on, the company had hired a consultant to handle the rewrite, while I managed another employee who maintained desktops, servers, printers, and more. The consultant had decided to move to Visual FoxPro backed by SQL Server. Since I had experience with FoxPro, SQL Server, and infrastructure, I ended up managing and participating in both sides of this environment.

I had more experience with SQL Server and the consultant had more experience with Visual FoxPro, so I handled setting up the database and discussing some of the data modeling choices with him. He made all the OOP and VFP decisions, with the estimation that this would be a 8-10 month project. After all, we had an existing system, most of the business rules were already encoded, and we weren’t looking to add much functionality.

Over the first 2-3 months, regular meetings showed me code being written, with some basic scaffolding of the objects we’d used and the various properties and methods that were required. We agreed on a object to relational mapping, and things seemed to be going well.

The first issue that set us back was a disk crash early in month 3. The consultant had been backing up work to a zip file on his machine, but not the network. You can cry along with me guess what happened. His machine crashed, and we were slightly stuck. Fortunately, we discovered a copy of code that was weeks old, and managed to restart development.

At this point, we had no VCS in place and my boss wasn’t interested in buying VSS. I decided on a simple setup. We worked off file shares for all code, with coordination on which files we’d edit (we were across the hall from each other). We also scripted a simple method to zip up all code and copy it to a different folder for each day of the week. Rudimentary, but it gave us some control in the mid 90s.

About 6 months in, my boss started to ask questions. Where were the prototypes? Where is something to test. We put him off, showing him some basic objects, and explaining how we were front loaded with setting up new classes to better handle our business rules. We were coming from a procedural system, so much of the code had to be rewritten to work in an OOP environment.

I was told that we needed to move, so I started joining in with coding. Up to this point, I’d just done some reviews, and now I needed to brush off some of my OOP skills from college as well as learn more about VFP, which was different from FoxPro.

Over the next few months, I started pushing us to make decisions and move, rather than debate whether we needed to set parent methods that would be shared by multiple subclasses. I argued with our consultant, insisting we move on, even if we had to store some code in both subclasses. We needed to get work done.

This was a fairly complex inventory and order entry system, unique to our business, and somewhat large for two people. At 8 months, we still didn’t have a working prototype, though we had certain items built and could show to users.

We also had change orders coming in, with requests to alter some functionality that wasn’t as useful or relevant as it had been in the past. My ability to help rose and fell as other issues came up, so development was sporadic.

Finally at about 12 months, we were close enough for testing that we decided to order a production database server. It was a nice, large Compaq. I think a PII, with 2GB of RAM and 5 or 6 internal SCSI drives. It came in multiple boxes, and we spent a day or two assembling pieces and installing the OS and SQL Server.

We built the database, ran a test migration that worked flawlessly failed miserably, but we managed to tweek things across a few days and get most data moved to create what would be our QA environment. We were feeling good as we walked from the server room to our desks. We walked back to our desktops and started the application, and checked on some data. Things worked, so time for QA.

We let some management know that we were close and one of the department heads volunteered one of his order entry people to do some testing. This young lady came over and sat at our desk, trying to process a few orders that she’d entered the week before. She entered a customer and clicked search.

And watched. It took maybe 15s to load the information, which was waaaaaaayyyyyy slower than our Fox for DOX application. Still, she persisted. She entered a partial product and searched for inventory, and

the results appeared to her delight after about 1 minute and a half. She was less than impressed.

We were slightly horrified. How could this server run slower than our workstations, which were mostly 64MB of RAM. Why wasn’t our 2GB server flying compared to the DOS app?

It took a little time, some research, and lots of questions to realize that the amount of data we had was coming from disk, with SQL Server’s optimizer deciding how to search, how to compile a plan, and how to read from disk. This was a problem, with spinning disks not performing as optimally as we’d like. Things were better once we’d warmed the cache, but users were not thrilled with early tests.

We continued working, across a few more months to finish the application to the point where users could switch. At this point, we were about 16 months in and it felt like we’d never get there, but we got far enough that we could migrate data and switch, changing a few procedures for functionality that would take longer.

My boss and the owner, who were business people, were less than thrilled with the length of this project, but we had improved a lot of features along the way, and they didn’t fire us because of the delays. We cut over, and while slow in the first hour, the system improved over the day and once users got used to some new ergonomics, they were pleased.

Of the several issues encountered with SQL Server ― SQL Server gets slower with time, generation of reports becomes tedious, SQL Server crash, performance issues and more ― the most troublesome for DBAs is the crash or failure of SQL Server. Reason being, the repercussion is a damaged or corrupt SQL Server database.

This is a huge setback as the SQL database cannot be accessed anymore, thereby restricting the access of the data stored in the SQL Server database as MDF (primary) and NDF (secondary) file. Consequently, it brings in the necessity of using a SQL recovery software to repair the damaged or corrupt SQL Server database (MDF and NDF) files easily and efficiently.

This is what happens when a SQL Server database fails or crashes, and how the Stellar software deals with those situations.

Irrespective of the reason, the software repairs the SQL server database.

The SQL database repair software repairs the damaged or corrupt SQL database MDF file (and associated NDF file) successfully.

When it is used, the result is a robust SQL Server database.

The Stellar software recovers the following SQL Server objects.

Note: The software saves non-recovered views, queries, tables, stored procedures, etc. in a separate text file so that it is easy to identify the non-recovered objects.

The SQL database repair software fixes different SQL server database corruption errors such as:

After the review of SQL repair software , I have comprehended the following about it.

Not just the Live or new SQL Server database, the software helps to save the recovered objects in other file formats such as XML, CSV, and HTML.

Thus, the recovered data of SQL Server can be accessed on multiple platforms.

Displays all recoverable items of SQL Server database in a tree-like structure before saving. This helps to select and preview the recoverable data easily.

The benefit of the preview feature is that you can verify whether the recovered data would be intact and in its original form.

The software provides an option to search Objects with the use of ‘Find Items’.

The advantage here is that users need not search the objects manually ─ which would take more time ─ from the list displayed after the scan process.

Plus, users can search for intended items based on ‘Match whole word’ or ‘Match case’ criteria.

This option enables users to save only the required SQL database objects.

From the list of the recovered database objects, users can select the required objects and save them.

The software offers to save the recovered SQL Objects at the user-defined location in addition to the default location.

Moreover, it allows to save the non-recovered Objects such as queries, views, stored procedures, etc. in a text file.

I found that the software works in three simple steps:

You can also check the three simple steps in the main interface of the software that is displayed in the figure below:

The software acts diligently when the ongoing SQL database repair process gets disrupted. It reconnects automatically and completes the repair process.

Next, the software automatically saves the scan information once the Scan process gets complete. The saved Scan information can be used to repair the database file at a later stage without the need to scan the MDF file again. This, thereby saves time.

Whenever DBAs need to repair a damaged or corrupt SQL Server database, they can use this handy and self-explanatory tool. With its advanced GUI ― a ribbon in the software interface with various options including customizable Menu items ― the software is easy to use. The automatic saving of Scan information that avoids the need to re-scan, simple three-step repair process, selective recovery for SQL objects, preview of recoverable objects, saving of objects at desired location, option to save in multiple formats, recovery of SQL objects, etc. ─ all these make the software effective to deal with SQL database corruption. These multiple functionalities owe to the advanced algorithms of the software. It is comparatively better than its previous versions as well as many other SQL repair software.

Nonetheless, there is a scope to increase the efficiency of the software so that it gives better results. This will make it perfect for DBAs handling SQL Server. Based on the features, benefits, and ease-of-use, I can rate the software 8 on 10.

https://www.cybrary.it/0p3n/3-best-sql-database-repair-tool-database-administrators-dbas/

XML is a data format used to share data in a form that can be easily used and shared. There is often the need import XML files into SQL Server which can be done several ways and in this tip we will look at a simple way to do this using just T-SQL commands.

There many possible ways to perform this type of import and in this tip we will show how this can be done using T-SQL and OPENROWSET to read the XML data and load into a SQL Server table. In order for you to understand it better, let’s walk through an example.

Let’s create a simple table thatll store the data of our customers.

Below is sample XML data. You can use this as is or modify for your own tests. I copied this data and stored in a file named MSSQLTIPS_XML.xml .

Now all we need is to make SQL Server read the XML file and import the data via the OPENROWSET function . This function is native to T-SQL and allows us to read data from many different file types through the BULK import feature, which allows the import from lots of file types, like XML.

Here is the code to read the XML file and to INSERT the data into a table.

After the insert, you can query the table to check the results:

Last Update: 2018-10-10

Related Resources

有个系统，昨天Support人员发布了相关升级脚本后，今天发现系统中有个功能不能正常使用了，直接报超时了（Timeout expired）错误。定位到相关相关存储过程后，然后在优化分析的过程中，又遇到了执行计划COST “ 欺骗 ” 我们的这种情况，其实在我这篇博客 ” SQL SERVER中用户定义标量函数（scalar user defined function）的性能问题 “ 有提及这个问题，但是很多时候，我们优化SQL的时候，会习惯去查看实际执行计划COST所占的开销比例,从而判断性能开销最大SQL语句。当然大多数时候，这也是正确的。我们先来看看这个案例吧，如下所示，这个存储过程的部分实际执行计划如下（实际执行计划实在太长，无法全部展现）：

我们将实际执行计划保存为sqlplan类型的文件（Execution Plan Files），然后用Plan Explorer展现出来，如下所示，Est Cost% 和 Est CPU Cost% 显示第一个SQL语句是整个存储过程里面开销消耗最大的SQL语句。然后去测试验证，发现这个SQL不是开销最大的SQL，也就是说执行计划欺骗了我们，实际上，下面Est Cost %为13.3的SQL才是性能开销最大的SQL

从实际执行计划中找到elapsed time最长的SQL 这个SQL才是真正影响性能的SQL语句，然后查看这个SQL，发现其查询条件（WHERE）使用了自定义标量函数（因为修改业务逻辑，查询条件添加了自定义函数过滤数据），然而这个从实际执行计划去看也是看不出问题的，因为这个自定义标量函数哪怕调用了几十万次，它的开销代价在实际执行计划中并没有呈现出来。具体原因截取 “ SQL SERVER中用户定义标量函数（scalar user defined function）的性能问题 “ 中的一段翻译如下：

翻译：

但是需要再次注意，执行计划在欺骗你，首先，它意味着只调用了UDF一次，其实不是这样。其次，从成本（Cost）来看，你可能会认为0%是向下舍入影响，因为单次执行函数的开销如此之小，以至于执行100,000次的成本也很小。但如果你检查执行计划的功能迭代器的属性，你会发现所有的操作代价和子树代价实际的估计为0，这是一个最糟糕的谎言。因为它可能不只是为了欺骗我们，而是SQL SERVER为了欺骗它自己。实际上是查询优化器认为调用函数的成本为0，因此它生成的所有执行计划都是基于调用UDF是免费的。其结果是即使调用标量UDF的代价非常昂贵，查询优化器也不会考虑优化它。

其实又单独总结一下这个问题，是因为人们或多或少受习惯性思维的影响，哪怕我之前多次遇到这种案例，但是在调优过程中，我还是会习惯性按照实际执行计划的COST比例去定位性能开销大的SQL语句，直到我通过验证推翻了这个判断，然后通过elapsed time最长的SQL语句才定位到开销最大的SQL。所以在调优、优化过程中，一定要多方位着手，反复推敲验证，不能被经验主义牵着鼻子走！

In my blog Calculating a Security Principal’s Effective Rights. I built a view, named Utilty.EffectiveSecurity that you could query to fetch a security principal’s rights to objects in a database. In that blog I tested the code and showed how it works. Now I have taken this to the extreme and expanded the view to include all of the user’s security by finding all of their rights to all of the things that the get rights for.

The list of possible permissions you can fetch can be retrieved from:

This returns the following 26 types of things that can have permissions assigned and returned by the sys.fn_my_permissions function:

Table variables are another types of temporary objects to store transient data. Please refer Temporary Table objects for more details about Temporary Tables in SQL Server.

So, now we should be good enough to take a decision on when do we need to use table variable and Temporary tables. I would like to reiterate statistics as one of the most important factor. Table variable does not have statistics where as temporary table has statistics maintained. As SQL Server optimizer is based on cost- based optimization, statistics are very important factor for Cost based approach to identify the best plan for your query. If your transient data is more than 100, I would suggest to use Temporary tables(with right indexes) over table variables to make use of the statistics to help SQL Server to identify the best plan for us.

In other words, if you have very less data, then I would prefer to use table variables over temporary tables. If you need to store data in a user defined function, table variables are the way for you currently. The choice is not hard rule one, but choose the best for your needs/requirements.

Hope you enjoyed this post, please share your feedback and thoughts.

I have to send the report to management every morning . For that i have create schedule in Sql Server agent with following code.

Now the problem is, the file which i need to send as attachment will generate every day with new name. File name will be in format

In above file name only the date value will be change. The date will be in ddmmyyyy format.

Now Kindly suggest me how can i achieve this. How send mail automatically with attachment.

Could you try,

Resource Governor can be used to enforce a hard cap on query MAXDOP , unlike the sp_configure setting. However, query plan compilation does not take such a MAXDOP limit into account. As a result, limiting MAXDOP through Resource Governor can lead to unexpected degradations in performance due to suboptimal query plan choices.

We start with the not often seen here three table demo. I’d rather not explain how I came up with this sample data, so I’m not going to. I did my testing on a server with max server memory set to 10000 MB. The following tables take about half a minute to create and populate and only take up about 1.5 GB of space:

I thought up the theory behind this demo on a car ride back from a SQL Saturday, but wasn’t able to immediately figure out a way to get the query plan that I wanted. I ended up finally seeing it in a totally different context and am now happy to share it with you. Consider the following query:

The MAXDOP 1 hints results in a serial plan with two hash joins:

This is a perfectly reasonable plan given the size and structure of the tables. There are no bitmap filters because row mode bitmap filters are only supported for parallel plans. Batch mode is not considered for this query because I’m testing on SQL Server 2017 and there isn’t a columnstore index on any of the tables referenced in the query. On my machine a single query execution uses 2422 of CPU time and 2431 ms of elapsed time.

A parallel plan at MAXDOP 4 is able to run more quickly but with a much higher CPU time. A single execution of the MAXDOP 4 query uses 5875 ms of CPU time and 1617 ms of elapsed time. There are multiple bitmap filters present. I zoomed in on the most interesting part of the plan because I haven’t figured out how images work with WordPress yet:

Instead of doing a scan of the LARGE table, SQL Server instead chooses an index intersection plan. The cost of the additional hash join is reduced by multiple bitmap filters. There are only 2648396 and 891852 rows processed on the build and probe side instead of 8 million for each side, which is a significant gain.

Some end users really can’t be trusted with the power to run parallel plans. I thought about making a joke about an “erik” end user but I would never subject my readers to the same joke twice. After enforcing a MAXDOP of 1 at the Resource Governor level, you will probably not be shocked to learn that the query with the explicit MAXDOP 1 hint gets the same query plan as before and runs with the same amount of CPU and elapsed time.

If you skipped or forget the opening paragraph, you may be surprised to learn that the query with a MAXDOP 4 hint also gets the same query plan as before. The actual execution plan even has the parallel racing arrows. However, the query cannot execute in parallel. The parallelism and bitmap operators are skipped by the query processor and all of the rows are processed on one thread:

I uploaded the query plan here if you want to look at it. This type of scenario can happen even without Resource Governor. For example, a compiled parallel query may be downgraded all the way to MAXDOP 1 if it can’t get enough parallel threads.

The query performs significantly worse than before, which hopefully is not a surprise. A single execution took 12860 ms of CPU time and 13078 ms of elapsed time. Nearly all of the query’s time is spent on the hash join for the index intersection, with a tempdb spill and the processing of additional rows both playing a role. The tempdb spill occurs because SQL Server expected the build side of the hash join to be reduced to 1213170 rows. The bitmap filtering does not occur so 8 million rows were sent to the build side instead.

In this case, adding a MAXDOP 1 hint to the query will improve performance by about 5X. Larger differences in run times can be easily seen on servers with more memory than my desktop.

If you’re using using Resource Governor to limit MAXDOP to 1, consider adding explicit MAXDOP 1 hints at the query level if you truly need the best possible performance. The MAXDOP 1 hint may at first appear to be redundant, but it gives the query optimizer additional information which can result in totally different, and sometimes significantly more efficient, query plans. I expect that this problem could be avoided if query plan caching worked on a Resource Governor workload group level. Perhaps that is one of those ideas that sounds simple on paper but would be difficult for Microsoft to implement. Batch mode for row store can somewhat mitigate this problem because batch mode bitmap filters operate even under MAXDOP 1, but you can still get classic row mode bitmaps even on SQL Server 2019. Thanks for reading!

SQL Server 2019 CTP was recently released. There is some information posted about new features such as this document by Microsoft What is new in SQL Server 2019 and this article on mssqlTips What's New in the First Public CTP of SQL Server 2019 . What other new features are there that can be useful to a DBA's daily operations?

As a SQL Server DBA, we are always excited about a new release of SQL Server. I once wrote a tip Identify System Object Differences Between SQL Server Versions and by using the script in that tip, I have explored the new objects and new changes for existing objects, such as new columns for views/tables or new parameters for functions/stored procedures.

Here are the detailed steps and some interesting findings in SQL Server 2019.

To find what’s new in SQL Server 2019, we need two versions of SQL Server. I will use SQL Server 2017 and SQL Server 2019. To follow along, you should have these two SQL Server instances installed.

Once step 2 is done, we can start to do some interesting exploration. We first take a look at the system object changes in SQL Server 2019 since SQL Server 2017.

We get 53 new objects, the last few are shown below:

The result is two extended stored procedures are dropped:

Now we take a look at the new columns added to system tables and views:

We see 75 changes; a sample of the changes is listed as below:

Now we will check the parameter changes to functions and stored procedures:

We can see the following changes:

In the new stored procedure / functions, I am pretty interested in the 3 new extended stored procedures:

Before SQL Server 2019, for all copy and delete operations, we needed to rely on xp_cmdshell with embedded copy and delete commands, but with these three new SPs, we can do our work in a more T-SQL native way.

The basic syntax is:

There is another interesting new table valued function, sys.dm_db_page_info, it has the following syntax

This view will surely be an important tool for internal storage troubleshooting. A quick example is like the following:

I get the following:

If you’ve done much with IN (list) then you’ve realized that it basically translates out to

You’ve probably also realized that you can throw all the values into a temp table and do this

But which is faster? Well, let’s find out. First I’m going to create a table of 1,000,000 values to pull against. This way I will hopefully get some useful times and not one that takes 10ms and the other 9ms.

tl;dr;It was pretty inconclusive even at large numbers of values.

I’m going to do some tests of various sizes. The first one will be a small test of just 10 values.

Now using the query printed out:

I ran this twice and discarded the first run because it was loading the data into memory. Yes, I realize that could be useful information, but I’m skipping that part of it for today.

Ok, so the logical reads are about the same. More from the IN (SELECT) actually, but only by a fraction because of the read on the temp table and some work tables. The time, however, was almost exactly half using the temp table. Now, this was without any indexes. So now I’m going to run the same queries again but this time having put a non-clustered index on ListTable.

This is a pretty simple index, and I don’t have a clustered index, nor is this a covering index but honestly, it’s a SELECT * so a covering index isn’t likely anyway.

This time the results are:

Oddly enough slightly less reads for the IN (SELECT) this time and it’s only slightly faster. I’m also tried adding an index on the temp table but with no significant change.

Summary (10 values)

With a small test (only 10 values) the IN (SELECT) was faster, with or without an index.

Large test (1000 values)

I’m going to use the exact same process as above but I’m not going to actually post the query because I feel like it will be too long for a blog post. Here is the code to generate the query though if you want to play along. I did have to make a few changes. The TOP became a TOP (1000) instead of a TOP (10) , the varchar(1000) became a varchar(max) and the PRINT became a SELECT because you get more information that way.

Without the index: (I’m skipping IO this time because it didn’t seem to tell us much last time)

Hmm, faster for the IN (list) this time. Let’s try it with an index on ListTable.

Still a bit faster for the IN (list). And again, I tried with an index on the temp table with no major difference.

Summary (1000 values)

This time the IN (list) was faster with and without indexes. By less than a second though.

Summary (10000 values)

I also did a test with 10,000 values. In this case, the IN (list) was still faster without an index, but once I put an index on the table the IN (SELECT) became faster, and with an index on both the table and the temp table it was a bit faster.

Over all summary

My results were really pretty inconclusive. I was really surprised since I truly expected the IN (SELECT) to be faster. Particularly with an index. But in the end, the timing wasn’t significantly different (a few seconds here or there) and I can’t be certain if that’s not something I’ve done wrong. So for most cases, I’m just going to use the version more convenient. For cases where even a fraction of a second matters (100’s of runs a second anyone?) I’m going to have to test to see which is working fastest in that case.

I decided to start a series of blogs where I interview key people in the SQL Server community. Instead of me asking technical questions, I plan on asking about their outlook on the future, books they read (non-fiction and/or technical), and their overall thoughts on where technology (mainly SQL Server) is headed. You can find more interviews here .

Next up: Drew Furgiuele ( b | t ):

Mohammad: Do you think people who dismiss the cloud as a “fad” or just don’t take it serious enough to learn about it (i.e. Azure, AWS, etc), will be in a tough spot to find a job 5 years from now?

Drew: I think we’re well enough into the era of cloud computing that everyone should at least know not just what a cloud provider like Azure or AWS is, but also what different services they offer. It’s not enough anymore to say “oh yeah, I’ve worked with the cloud.” I think most people who want to explore this space should be at least to say something like “I’ve stood up a database as a service in Azure” or “I’ve built a VM in EC2.” And if you can’t, there’s still plenty of time to start learning. Oh and by the way, more and more services are coming to cloud providers each and every day. I don’t think that NOT knowing these things puts any kind of expiration date on your current job, but if you’re looking for new opportunities, you might start to find yourself at a disadvantage.

Mohammad: Do you ever see the traditional SQL Server DBA role being replaced/eliminated?

Drew: Nah, I don’t think DBA jobs are going away… but I *do* think the DBA roles (as well as future DBA job descriptions) are changing. It’s not enough to know just how to take backups and apply indexes anymore. I think the DBA role needs things like automation experience (like PowerShell, or bash), and some exposure to DevOps. You can’t discount the need to learn new platforms either, like linux. Suddenly, it’s not enough to know just how to restart a SQL Server instance anymore; you need to know how to restart a service on windows AND Linux. We’re also in new territory with containers, too. It’s and exciting time for DBAs… if you’re not against setting aside time to learn .

Mohammad:What are you most proud of doing/accomplishing for the SQL Server community so far in your career?

Drew: I know I have a lot to be thankful for and proud of but honestly, I think I was at my best when I was working on the HASSP project . It was silly, stressful, and fun all at once and I got to work with some pretty amazing people on it. We’re not done, either, so if you want to catch up on what we’ve done so far that link will take you to the first post announcing the project, and I’ve got a running diary of blog posts detailing the journey (so far) .

Mohammad: What non-technical/non-fiction book/s would you recommend? If you only read technical books…what do you recommend?

Drew: I like a good technical book as much as the next person, but I really like historical, non-fiction books the most. I’ve recently finished a couple really good ones. First, it was “ The Hunter Killers ” by Dan Hampton which tells the story of the Wild Weasel program in Vietnam, and the nerves of steel that those pilots and radar operators had to possess to basically be missile bait and put their lives on the line for other air crews. It’s got a nice mix of anecdotal references and historical storytelling to make it a fun read about a difficult time to be an airman. I also just finished “ The Taking of K-129 ” by Josh Dean which talks about one of my favorite stories ever: Project Azorian, or the CIA’s attempt to steal a long-thought-lost Russian submarine from an impossible depth. It’s equal parts spy thriller and technical manual that talks about just of how crazy of an idea it was, to the people who helped solve incredible technical problems using then-unproven technology. It’s harrowing and unbelievable, but they really did it (and just how successful were they? Or do we STILL not know the whole story? Check it out!

Mohammad: For someone who’s career focus has been on one aspect of SQL Server (i.e. Database Engine), do you think it would be wise for them to become a “jack of all trades” by starting to learn, SSRS/IS/Azure, etc. or remain focused on their area of expertise? In another words, which would you say is more valuable? mile wide / inch deep or inch wide / mile deep?

Drew:I think the answer lies somewhere in the middle. I know that for me, my career really took off once I started exploring automation. Just saying “I want to learn how to do ‘X’ with PowerShell” has opened a lot of avenues for me. For instance, my day job is “Senior DBA” but I recently joined a project team focused on a big data implementation, and one of the first things I’m doing for that team? Automation! I get to do something new and exciting, all while learning about big data pipelines and specifically, how to set up automation around getting data to a distributed system, training models, implementing the models, and then ultimately processing and consuming the data. I did have to step away from some of the day-to-day DBA things, but in the end I’m getting to apply skills I already have and learn a bunch of new things in the process, like Azure Databricks and python. I think this just a really long way of saying that I think the days of just knowing SQL Server isn’t enough, and you should absolutely diversify your skills portfolio .

Mohammad: Lastly, I really believe in not only learning from your mistakes but, if possible…learning from the mistakes of others. What is your biggest mistake? If you could go back in time, is there something that you regret not doing? And if so, what?

Drew: My biggest mistake was getting too comfortable. I was at my last job for eleven years and while I can’t say with the utmost confidence that had I stayed I would still be there, but there was plenty to work on with lots and lots and lots of technical debt that needed solved. For all I know, it might still need solved. Regardless, my skills languished because I wasn’t getting to work on too much new stuff, and I had this crazy idea that I wanted to try people management. I did get my shot at it, and it was fine… but I found myself missing the deep technical challenges I was used to solving. When I did finally muster up the courage to leave that role (and company) it turned out to be the best thing I ever did for career and well-being. I have never been more energized, challenged, and ultimately fulfilled than I am now. I get to work with great people, solve tough problems, and still have a ton of fun. So my biggest regret is not having the courage to do it even sooner than I did. It all worked out, but it’s a fascinating “what if?”

In data science, understanding and preparing data is critical. In this article, in the series, we’ll discuss understanding and preparing data by using SQL transpose and pivot techniques.

Transposing a matrix means reversing rows and columns. The data frames in R and python are actually matrices, and therefore transposing is not a problem. A SQL Server table is a slightly different structure, where rows and columns are not equivalent and interchangeable. A row represents an entity, and a column an attribute of an entity. However, you might get data in SQL Server form a matrix from other systems, and meet the need to transpose it. Transposing data does not involve aggregations.

Pivoting is a similar operation. You need three columns for the operation. The first column is giving the row groups. The second column is transposed; its values are used for the new columns’ names. The third column gives the values, which are aggregated over rows and columns.

As you are probably already used to in my data science articles, I will start with preparing some data. I am using the data from the AdventureWorksDW2017 database. Note that I switched from the SQL Server 2016 version of this database I used in the previous articles to the SQL Server 2017 version. Don’t worry, the structure of the database and the data is nearly the same.

You can make a quick overview of the data with the following two queries. Note the distinct years returned by the second query.

The distinct years with sales are from 2010 to 2014. Besides years, I aggregated sales over countries and states as well. I also added a combined column CountryState in the table dbo.SalesGeoYear I will use further in this article.

Let me start with the T-SQL PIVOT operator. The following query calculates the sum of the sales over countries and years. Please note the syntax for the PIVOT operator. The sales column is used for the aggregation, and the CYear column for the labels of the new pivoted columns. Grouping is implicit; all other columns, not used for pivoting or aggregation, are used in an implicit GROUP BY.

Here is the result of the query.

Of course, you can change the aggregate function. For example, the following query calculates the count of the sales over countries and years.

You probably noticed that I used a common table expression to prepare the rowset for pivoting; I am not using the table directly. This is due to the implicit grouping. Somebody that defined the syntax for the PIVOT operator wanted to make the code shorter; however, because of that, you need to write more code to be on the safe side. Columns that are not used for pivoting and aggregating are used for grouping. What happens if you read a column more, like in the following query?

I read also the column State in the CTE. I am not using it in the outer query. However, the result is quite different from the previous one.

The query did implicit grouping over two columns, Country and State.

The PIVOT operator is not really intended for transposing the table. You always need to have an aggregate function. However, you can simulate transposing when you have a single value over rows and pivoted columns with the MIN() or MAX() aggregate functions. For example, the following query does not work:

But, as mentioned, it is easy to change it to a query that does work, the query that just transposes the data, without aggregation. Or, to be precise, the aggregation exists, with the MAX() function, on a single value, returning the value itself.

The PIVOT operator is T-SQL proprietary operator. It is not part of the ANSI SQL standard. You can write pivoting queries with ANSI standard SQL as well, using the CASE expression, like the following query shows.

Besides implicit grouping, there is another problem with the PIVOT operator. You can’t get the list of the distinct values of the pivoted column dynamically, with a subquery. You need to use dynamic SQL for this task. I am showing how to create a pivoting query dynamically in the following code. Note that I create the concatenated list of pivoted column names with the STRING_AGG() function, which is new in SQL Server 2017.

This will be enough T_SQL for this article, I am switching to R now.

As always, I am starting with reading the data from SQL Server in an R data frame. I am also using the View() function to show it immediately.

The simplest way to transpose the data is with the t() function from the basic package:

The transposed matrix is not very readable. Here is the partial result.

Cause sometimes you need to check why replication is slow or halted.

For example, like during an IO storm no hurricane pun intended. Say you have transnational replication over an Always On (SQL Server Availability Groups) environment that’s a publisher.

To see in the Dashboard just add the column, this is what it looks like when there’s a problem. If you’re wonder that number was 284.86GBs yup, it was a very busy day.

So to automate things, add the alert monitor as a step to a recurring SQL Agent Job to all replicas where it runs only if the node is Primary and you’ll get a nice email.

P.S. Go get ’em tiger.

emoji

Hiram

By: Aaron Bertrand || Related Tips:More >SQL Server 2019

Microsoft added a task in SQL Server Management Studio 17.5 called " Classify Data ." The purpose is to help identify columns that are potentially sensitive in nature, and that may need to be protected in order to remain compliant under various regulations, including SOX, HIPAA, PCI, and GDPR. It does a pretty good job of identifying vulnerable columns and helping you classify them depending on the risk and the type of exposure they present. But aside from showing you the results of this classification, this feature does not raise any additional visibility to these sensitive columns, never mind any suspicious access to them.

For background on the functionality introduced in SQL Server 2017 and SSMS 17.5, imagine we have this table:

When I run the wizard, I get the following recommendations:

You might not agree with all of the classifications, so you can change them, and even can add your own, specifying various information types and sensitivity levels. These are:

When you select the columns you want to classify, click Accept, and then Save, it adds extended properties around those columns. The report in SSMS uses those extended properties, and displays them as follows:

You could of course write your own app that consumes them, and maybe there are already tools out there that do, but nothing really happens here inside of SQL Server, except these extended properties exist and they surface the relevant columns on the report.

In SQL Server 2019, there is a lot more automation built into the system, allowing you to easily add sensitive data labels to columns, which will get pulled into audits by default. Let's take the same table above, and add our own sensitivity classifications similar to the ones we added above with extended properties, using the ADD SENSITIVITY CLASSIFICATION command ( already available in Azure SQL Database ):

These don't create extended properties, but rather we can see these in sys.sensitivity_classifications:

If we are creating an audit, we don't have to do anything special to pick up these classifications, except be auditing the table (in other words, existing audits will simply start inheriting these classifications as they are added). So, if we have a server audit:

Then a database audit that is monitoring read activity on the table:

With the audit enabled, if we run a couple of queries:

We can observe access to specific types of information this way, with the new column data_sensitivity_information that is included in the audit:

Results:

You can click on any XML column value to see these results:

It is interesting to note that FirstName and LastName combined to yield only one element in the XML. This means that whether you have one or 50 columns with a specific label and information type combination, it won’t add any unnecessary data to the audit. Anyway, for those of you that are XML-savvy, you can likely see how easy it would be to extract that information as nodes and then run queries against it, making it very easy to identify all the accesses to specific labels or label/type combinations.

I feel like there might be a market for a conversion tool that would translate these data classifications you may have already invested in (or built tools that consume) from extended properties to sensitivity classifications, or vice-versa. I'm not going to handle synchronization here, but I'll offer up a start, taking the extended properties and building dynamic statements to migrate them:

i am not the best with sql but i try my best to get my Problems done. I have a table "just" which is filled with Columns ( ID (PK, Identity), Char, Serv , Random ) . Now i want to select a random row from this table and insert it into the Table "f_WinGet". So far all my Procedures take this Step fine , but i always get Duplicates in the second table.

First table : 84 rows Second table: needed 35 random out of 84.

I have tried many other ways but i always get the same result. All my Procedure for random are binded to a Button i a C# Programm. All is working fine so far , but i always have some Duplicates of Rows in my Table.

It would be nice , if anyone hase an Idea how i can fix my Problem. I am still trying , but all what i get are always the same result.

With a table as small as yours you can use something like:

This way making sure that the values you're trying to insert is not on the final table.

This blog post is a part of the whole Batch Mode series, which can be found at the Nikoport Batch Mode page .

This post will focus on some of the initial limitations of the Batch Execution Mode on the Rowstore Indexes.

Please consider this as something that is absolutely expected to change in the future releases, and even though in some cases I seriously ask myself if the fixes will come rather late then soon, I still expect them to solve them all.

In any case without jumping ahead to the conclusion let’s consider what the Batch Execution on the Rowstore Indexes technically is. For me, it is a rather huge improvement over the previous hacks to inject the Batch Mode into the queries with the non-Columnstore Indexes … And given that the infrastructure for the processing of the Hash Match, Window Aggregates, Hash Join, different types of Sort and other operators supporting Batch Execution Mode, the essential 2 missing pieces were:

Heuristics (and take a look at the Batch Mode part 3 (“Basic Heuristics and Analysis”) for more details). Deciding when to kick of with the Batch Execution Mode is absolutely essential and this is the part which gives me a lot of fears of the scenarios when it shall kick off absolutely unnecessary, killing of the

The Index Scan iterator which would kick off with the Batch Mode, eliminating potentially a huge improvement of the data processing, should our tables have a huge number of rows.

Do not get me wrong, there were some stuff that I know and do not to put here, and there must have been tons of details that unless we become programmers at Microsoft we shall never find out, but I consider those 2 pieces to be the biggest blocks in the implementation.

We have already seen how Batch Mode can successfully turbo-charge the queries and improve them, I have also shown at Batch Mode part 2 (“Batch Mode on Rowstore in Basics”) an example of TPCH query, making the Batch Mode over the Rowstore Indexes to perform significantly slower, and in this blog post, let’s consider a couple of more scenarios where things do not go exactly the way we expect them to go over, by default.

Let’s build a “good” table with a Clustered Primary Key on the Rowstore Indexes to which we shall load just 2 million rows:

Let’s execute a rather dull aggregation over the only column that it contains and half the result while converting to the Decimal and grouping in the chunks of 10:

You will find the execution plan of this query below with all expected iterators running in the Batch Execution Mode:

Everything is shiny this is the standard we expect to have, if running a similar calculations against a single table, right ?

Let’s build an In-Memory table with the same 2 Million Rows and try running the very same query against it:

Running our test query against this table produces the following execution plan in the SQL Server 2019 CTP 2.0:

As we all know, LOBs are almost always one of the last feature to be implemented & supported think Online Rebuilds, even Columnstore Indexes (Clustered) got them in SQL Server 2017, while Nonclustered Columnstore Indexes still do not support them at all. This has probably to do with the amount of changes, complexity and storage requirements, and there won’t be a huge exception for the Batch Execution Mode consider the following example below where I create a new table that would almost be a copy of the original “good” one, but with a second column C2, that will be using VARCHAR(MAX) and where shall simply store NULLs:

The only thing that will change is that we shall insert a predicate searching for the NOT NULL rows in C2:

The execution plan will tell the whole story about how it affects the query, but the point here to make is that not a single iterator in this case will run in the Batch Execution Mode:

One of the very important points here is that it is enough just to search for the data in the LOB column in order to avoid the Batch Execution Mode, you do not have to aggregate on it and this will be a very big factor for some of the installations I know, where just a simple message column defined with a wrong data type will do a huge damage by not allowing the Batch Execution Mode to kick in.

I do not expect this one to be solved quickly and this worries me much more then just In-Memory tables.

XML ? What on the planet Earth do you mean by that, Niko ?

Now, in the age of JSON, who cares about the XML ?

Well … A lot of application around still do, and they will … :)

Let’s build another test table dbo.RowstoreXMLDataTable with an additional column C2, containing XML, that will contain primitive copy of the C1 row number surrounded by the delightful? <root> tag:

Running the summing query over our XML column will result in the following execution plan:

The execution plan has got it all … The Table Valued Functions, UDX, Stream Aggregates, etc. The only thing missing is the Batch Execution Mode and it ain’t coming back home.

While I am not the biggest fan of XML, it is a still very much needed format and its support should be implemented. It is not as high on the priority list as the LOBs but still pretty neat thing to have.

You did not expected it, did not you ?

Which is pity and given that it is nice feature, totally underused by the Data Professionals:

We still have some iterators execution with the Batch Mode, but the Scanning of the Spatial Indexes is a slow RBAR. :)

Given the complexity of the task and demand for it, I do not expect this one to get fixed until 2038. :)

Interesting here is that we can actually see the last_optimization_level property for the Batch Mode Heuristics to show a real value of 2 ...

Nope. Like in the case with Columnstore Indexes.

Ha!

At this point we are back to the TPCH drawing board and the query 19 is still here to stay - giving us some of the most incredible headaches, and not because the Batch Mode is not enabled in it - it is.

Below again the Batch Mode over Rowstore and Row Mode over Rowstore TPCH Query 19:

This is the query for the Batch Execution Mode:

, while the faster query which is using the Row Execution Mode:

The problem in the query above is that the Bitmap Filters are executed at the very late stage, after processing the regular filters, with all the rows being directly read from the dbo.part & dbo.lineitem tables - contrary to the Rowstore Indexes with the Row Execution Mode and being different to the situation of the Columnstore Indexes.

Strings are "kind of evil" and the Batch Mode is not their best friend, especially right now. If you are looking to test your workload right away with CTP 2.0, while working with a lot of strings (and oh so many Data Warehouses do that), please consider waiting a little bit before making a final decision, you will not regret it.

I have been told by Microsoft that this is one of the issues that is being worked on and that it is very much expected to be resolved before the RTM of the SQL Server 2019.

The limitations of the Batch Execution Mode on Non-Columnstore Indexes is mostly based on not-Rowstore data sources and their scans. There are some noticeable exceptions, such as LOBs, and they should be kept pretty much in mind.

Mostly those limitations are delighters, and not getting an extra snack is not the same as getting almost entire one.

Given that Microsoft expects the String Filters to get a significant improvement before the RTM, I feel pretty much comfortable looking into the future.

While of course, those perky LOBs, disabling the Batch Execution Mode are nothing short of being fine ... But I am a believer that this limitation will fade away in a relatively near future. (I have no such feedback/information from Microsoft, but I see a huge potential in the massive text processing that will eventually gain its space on SQL Server & Azure SQL Database).

The bottom line is to remember that the feature is called Batch Mode on Rowstore (and if you are not using Row Storage, you are most probably out of luck).

to be continued ...

When these versions of SQL Server were released, they came with 10 years of support; 5 years of Mainstream Support and 5 years of Extended Support. If your organization still has SQL Server 2008/2008 R2 in production, how is your organization planning to address the risk? For organizations that are heavily regulated, this is a big concern.

You need to choose how you’re going to migrate and where you’re going to migrate to, and then make sure you’re not going to hit any roadblocks along the way.

If you are planning an upgrade from SQL Server 2008/2008 R2, Microsoft has made things much easier to test and validate your environment. Numerous tools exist that can assist with migration assessments and even handle migration tasks, and they’re all slightly different. These tools include:

The Data Migration Assistant helps you to upgrade to a modern data platform. It does this by detecting compatibility issues that can impact functionality on the newer version of SQL Server and makes recommendations for performance and reliability improvements for the new environment. Your source can be SQL Server 2005+ with a target of SQL 2012+ and Azure SQL Database.

The Microsoft Assessment and Planning Toolkit has been around for many years and is often referred to as the MAP Tool. It’s great for doing an inventory of your current environment to find where SQL Server (and other applications) exist.

The Azure Database Migration Service integrates some of the functionality of existing tools and services to provide customers with a comprehensive solution for migrating to Azure. The tool generates assessment reports that provide recommendations to guide you through any changes required prior to performing a migration. This service currently requires a VPN or Express Route.

Finally, the Database Experimentation Assistant is a new A/B testing solution for SQL Server Upgrades and it’s a tool you should become familiar with. It leverages Distributed Replay to capture a workload and replay it against a target SQL Server. This can be used to test hardware changes or version differences of SQL Server. You can capture workloads from SQL Server 2005 and up.

On-premises upgrade:One of the easiest migration methods is to upgrade to a newer version of SQL Server. In this case, you have SQL Server 2012, 2014, 2016, or 2017 to pick from. I encourage clients to upgrade to the latest version that they can. SQL Server 2012 is already out of Mainstream Support and SQL Server 2014 goes out of Mainstream Support on July 9 th , 2019. Upgrading can be very time consuming and costly to organizations due to all the planning and testing involved, so moving to the latest version can increase the time before the next upgrade. There are also numerous performance and functionality improvements in SQL Server 2016 and 2017 that make migrating to SQL Server 2012 or 2014 a very poor choice at this time.

A common approach for on-premises upgrades is to build new and migrate, regardless of a physical or virtual environment. By building new, you can restore your databases and conduct numerous rounds of testing and validation to make sure everything works as expected before moving production.

Upgrade and migrate to an Azure VM:For organizations that are looking to migrate to the cloud, Azure Infrastructure as a Service (IaaS) is a great option. Running SQL Server on an Azure VM is much like on-premises. You specify the size of the VM (number of vCPUs and memory) and configure your storage for your I/O and size requirements. You are still responsible for supporting the OS and SQL Server for configuration and patching. Azure IaaS gives you the ability to easily scale your workloads by scaling the size of your virtual machine up or down as your workload needs change, as well as take advantage of Azure Active Directory integration, threat detection, and many other Azure benefits.

Migrate to Azure SQL Database:Another option you have is to migrate to Azure SQL Database. Azure SQL Database can be thought of as a Database as a Service and is part of Microsoft’s Platform as a Service (PaaS). Azure SQL Database functionality is database scoped, which means certain things such as cross database queries, SQL Server Agent, Database Mail, and more are not available. However, many customers that have applications that utilize a single database have been able to migrate to Azure SQL Database with minimal effort. You can quickly test for compatibility with Azure SQL Database by using the Data Migration Assistant. With Azure SQL Database, you can size your databases by DTU (Database Transaction Units) or vCores individually, or group databases into an Elastic Pool. Azure SQL Database allows you to scale your resources up and down with minimal effort and downtime.

Migrate to Azure SQL Managed Instance:A new option (as of 2018) is to migrate to Azure SQL Managed Instance. This is a new product that is currently generally available as of October 1 st for the General-Purpose tier. Managed Instance was built using the instance-level programming model. This means that functionality we are used to with the full version of SQL Server is supported. The goal of Managed Instance is to have 100% surface area compatibility with on-premises. All databases in the instance are on the same server, so cross-database queries are supported, as are Database Mail, SQL Server Agent, Service Broker, and much more. There are two pricing tiers; General Purpose, that includes a non-readable secondary for HA, and Business Critical, that has two non-readable secondaries and a readable secondary. Managed Instance is part of Microsoft’s PaaS offering, so you get all the built-in features and functionality of PaaS.

Move as-is to Azure Virtual Machines:Microsoft is offering three years of Extended Security Updates at no additional charge if you move your SQL 2008/SQL 2008 R2 instances to an Azure VM. The goal is to give you a bit more time to upgrade to a newer version of SQL Server when you are ready.

Pay to Stay:This isn’t a migration option, but you do have an option to purchase up to three years of Extended Security Updates. There are restrictions around this option. You must have active Software Assurance for those instances or Subscription licenses under an Enterprise Agreement. If this applies to you, then this option can buy you more time to plan and migrate off of SQL Server 2008/2008 R2.

When performing any migration or upgrade, there are certain things you need to be aware of. First, you need baselines and I can’t stress this enough. Anytime you make a change to an environment, you need to be able to measure how that change impacts the environment. Knowing key performance metrics for your environment can help you when troubleshooting any perceived impact. You can manually collect these metrics using perfmon and DMVs or invest in a performance monitoring platform. I wrote about both techniques in more detailin a previous post, and right now you can get an extended, 45-day evaluation of SentryOne . Having baseline metrics for things like CPU utilization, memory consumption, disk metrics, and more can quickly let you know if things look better or worse after an upgrade or migration.

You should also note your configuration options within your instance. Many times, I’ve been asked to look at a SQL Server instance after an upgrade or migration and found that most of the default settings are in use. If the old system is still available, I’m able to query it and get the previous non-default values that were in place and apply those to the new environment to get them back to a known configuration. It is always good to review sys.configurations on your production server to consider making similar changes on your new environment (cost threshold for parallelism, max degree of parallelism, optimize for ad hoc workloads, and more.) Notice I wrote ‘consider’. If your core count or memory is different on the new server, you need to configure the settings taking the new server’s size into account.

What is your backout plan if things go wrong? Do you have proper backups you can go back to? In most cases with an upgrade or migration, you are moving to a new VM or physical server. Your failback may be to move back to the old server. If you have had data change in the new version of SQL Server, your failback is much more complicated. You cannot restore a SQL Server database backup from a newer version of SQL Server to an older version.

If you are still using SQL Server 2008 or SQL Server 2008 R2, you have a few options available to you to stay in compliance after July 9th, 2019. To stay on SQL Server 2008 or SQL Server 2008 R2, you can purchase Extended Security Updates or move to an Azure virtual machine if you qualify. If you can upgrade, you can migrate to a supported version of SQL Server on-premises or on an Azure VM or consider migrating to a managed solution such as Azure SQL Database or Azure SQL Managed Instance.

Imagine I have this table:

How can I build a t-sql query to get the top 2 value rows and a third with the sum of others?

Something like this:

Thanks

In the assumption you are using SQL Server 2005 or higher, using a CTE would do the trick.

Kudo's go to Andriy for teaching me some new tricks.

【 dbForge Query Builder for SQL Server下载 】

您可以使用Query Profiler工具来调试，故障排除，监视和测量应用程序的SQL语句和存储过程。如果您的应用程序存在您认为可能由特别长时间运行的查询引起的性能问题，则可以分析查询持续时间。

在本文中，我们将介绍如何分析简单查询。作为示例，我们将使用Microsoft的AdventureWorks2012测试数据库。

分析SQL语句

我们将从Person表中选择名字为“Robin”的所有人。

1. 在“Start” 页面上，单击“Query Profiler” 。将打开一个新的SQL文档窗口。

2. 在文本编辑器中，键入以下脚本：

3. 单击“Execute” 。Plan Diagram窗口打开。

请注意，选择图标包含警告标记，用于警告缺点。将鼠标指针悬停在“Select” 图标上时，会自动显示工具提示。工具提示的底部包含警告消息，告诉我们索引缺失。要添加索引，请执行以下脚本：

现在我们可以回到Query Profiler，然后单击Get New Results按钮。

每次获得执行查询的分析结果时，它们都会在树视图中显示为具有查询执行时间和日期的新节点。编辑查询时，您想知道更改是否会缩短查询执行时间。Query Profiler可以快速比较分析结果。要比较结果，请按住CTRL键并选择两个计划图。

注意：在获取查询分析结果后保存查询文件时，后者将自动存储在* .design文件中。

购买dbForge Query Builder for SQL Server正版授权的朋友可以点击" 咨询在线客服 "哦~~~

本站文章除注明转载外，均为本站原创或翻译。

欢迎任何形式的转载，但请务必注明出处，尊重他人劳动成果

{@@OriginalPath}

“I want to view the file size of MDF file but when I tried to retrieve the data from mdf file I am getting SQL errors. I think my master database file got corrupted as my SQL Server got abnormally shutdown few days earlier. I am not sure if I am right or not in case of Mdf file corruption. Please tell me how to view corrupt MDF file in SQL Server, also I want to know reasons behind MDF file corruption.”

MDF File corruption is one of the worst scenario any user faces as all the data of SQL database is stored in MDF File. It stores all the database components like functions, tables, triggers functions etc. But what if it get corrupted? The data present in the MDF file has high chances of getting lost if not repaired properly.

If your MDF File is corrupted and you are unable to access it then get to know how can you view corrupt MDF file. Before proceeding to the solution, you must be thinking the reason of this disaster. Let us understand what could be the possible reasons of getting SQL MDF File corrupted.

SQL MDF file is highly prone to database corruption. So one must take regular backup check of this file. Coming to the reasons, there could be number of reasons behind MDF File Corruption.

Some of them are as below:

One of the major reason of getting SQL database corruption is IO Subsystem. It is estimated that 99% of corruption in mdf file is caused due to this I/O Subsystem.

Beaware from these causes! Prevent your MDF file from getting corrupted by taking regular recent backup!!

We have discussed various possible reasons why MDF File got corrupted. Now let us discuss how can you view your corrupted SQL MDF File.

I have created SAMPLE2 database and made it corrupted. As you can see in the image, when I tried to retrieve the records through the SAMPLE2 database it give me Corruption error 5172.

Now I am using SysTools SQL Recovery Tool to view corrupt MDF File. Here is how:

Free Download

100% Secure

Hence, you are successfully be able to view all recovered database objects, that corrupt SAMPLE2.mdf file contains

1. I am using SQL Server version 2014. I don’t have log file of my database. Am I be able to view corrupt mdf file of my database ?

Sol: Yes, MDF File repair tool allow you to preview .mdf file data even if you don’t have log file. Just load the file to the software and you will be able to preview all data.

2. I ran DBCC CHECKDB command with REPAIR_ALLOW_DATA_LOSS option to repair my MDF File so that I can view all the details of it. But when I execute Repair statement, it got failed in repairing my .mdf file. Can I be able to view my MDF file data?

Sol: Yes , You can repair your .mdf file by simply loading it to the software. The software scans and recover MDF File data of SQL version 2017 , 2016 & all below versions.

3. I am using SQL version 2017 and I am getting Error Msg 823 error. Is it possible to recover and view corrupt MDF File while having SQL error 823 with this software?

Sol: Yes, the software repair your MDF File if you are having Msg 823, 824, 825 in SQL Server. Not only this, the tool repair MDF File from all type of corruption like page level corruption, meta data corruption etc.

All those users who are looking for a way to view corrupt MDF File in SQL Server are welcomed here to find out the solution. Possible reasons of MDF getting corrupted has also been discussed. Some user queries has also been discussed for the same.