Comments
Sort by recent activity
That's odd behavior. I'll see if someone from the team can look into it. / comments
That's odd behavior. I'll see if someone from the team can look into it.
I've been running it on a 200gb backup and it takes around 40 minutes (on very weak hardware) to create an image. However, it's a single file backup. I haven't tested it on a multi-file backup yet. / comments
I've been running it on a 200gb backup and it takes around 40 minutes (on very weak hardware) to create an image. However, it's a single file backup. I haven't tested it on a multi-file backup yet.
One thing you can do is to go to the little gear symbol on the left and click on it. There you can turn off all columns that are identical. It doesn't filter as such, but you'll only be left with the columns that have actual differences. That should make things a lot easier to deal with. / comments
One thing you can do is to go to the little gear symbol on the left and click on it. There you can turn off all columns that are identical. It doesn't filter as such, but you'll only be left with t...
JeremyL wrote: »
Thank you Grant, I was not aware of that feature. It helps slightly but still doesn't solve the root issue of scrolling through thousands/millions of records trying to find the few differences of a particular column.
Yeah, sorry. It's just not currently set up to search & filter on the data returned. If you really need to dig into that in that manner, I'd suggest using T-SQL queries at this time. / comments
JeremyL wrote: »
Thank you Grant, I was not aware of that feature. It helps slightly but still doesn't solve the root issue of scrolling through thousands/millions of records trying to find the...
The syntax seems correct. Let me check with the team. / comments
The syntax seems correct. Let me check with the team.
In some instances the sizes reported by databases can be off. You can try DBCC UPDATEUSAGE to clear that up. More here. / comments
In some instances the sizes reported by databases can be off. You can try DBCC UPDATEUSAGE to clear that up. More here.
It does depend on what kind of performance testing we're talking about. If you want to measure specific query timing metrics, or your disk I/O timings for the server or database, then absolutely not. The overhead introduced by SQL Clone will skew those results.
However, if you're looking at query tuning by using execution plans, then yes, absolutely. The plans generated are going to be the same, using Clone or not. If you're looking to see the volume of I/O of a query, how many pages it reads, then you can also use Clone as part of your performance tuning.
For me, it's whether or not you're attempting to measure system metrics or more granular information. The system metrics, especially I/O are going to be somewhat skewed because of Clone. Most of the other measures are going to be good enough for you to understand what's going on in terms of performance tuning. Just go into it with the knowledge that I/O speed is not something you can accurately measure because of Clone. The rest should be OK with that knowledge. / comments
It does depend on what kind of performance testing we're talking about. If you want to measure specific query timing metrics, or your disk I/O timings for the server or database, then absolutely no...
Generally to get to a multi-step deployment, a lot of people are using deployment software like Team Services Deployment Manager or Octopus. That allows you a very high degree of control on putting additional pre & post steps in line with your Source Control deployments. / comments
Generally to get to a multi-step deployment, a lot of people are using deployment software like Team Services Deployment Manager or Octopus. That allows you a very high degree of control on putting...
Just an FYI on this one, I've been using the tools with SSMS 2017 for quite a while. They work really well. Now, connecting to SQL Server 2017 you might see some hiccups. Let us know. / comments
Just an FYI on this one, I've been using the tools with SSMS 2017 for quite a while. They work really well. Now, connecting to SQL Server 2017 you might see some hiccups. Let us know.
The principal difference is that Microsoft can read the structure below the encryption and then back that up through compression and encryption. It's a difference between access to the underlying code and no access to the underlying code. / comments
The principal difference is that Microsoft can read the structure below the encryption and then back that up through compression and encryption. It's a difference between access to the underlying c...