CREATE TABLE #DMVResults (
ID INT IDENTITY(1,1)
, DMV VARCHAR(256)
, Scope VARCHAR(50)
, RequiredPermissions VARCHAR(256)
, SupersetPermissionThatAlsoWorks VARCHAR(256)
, YouHaveIt BIT
)

DECLARE @DMVCode VARCHAR(120)
DECLARE ZCursor CURSOR LOCAL FAST_FORWARD FOR
(
SELECT ‘EXEC dbo.DmvPermission @dmv=”sys.’ + name + ”’;’
FROM sys.system_objects
WHERE name LIKE ‘dm_%’ AND type = ‘V’
)
OPEN ZCursor
FETCH NEXT FROM ZCursor INTO @DMVCode
WHILE @@FETCH_STATUS = 0
BEGIN
INSERT INTO #DMVResults (
DMV
, Scope
, RequiredPermissions
, SupersetPermissionThatAlsoWorks
, YouHaveIt
)
EXEC (@DMVCode)
FETCH NEXT FROM ZCursor INTO @DMVCode
END

CLOSE ZCursor
DEALLOCATE ZCursor

SELECT *
FROM #DMVResults
WHERE RequiredPermissions ‘VIEW SERVER STATE’

1.) Selective Table Restoration
SQL Server does not have a native way to restore only one table from a backup. This means that if you need to recover a single table from a backup, you must recover the whole database. This can take a lot of time and resources, especially for large databases.

Restoring tables selectively would let users recover only the tables they want, saving time and resources. This feature would be handy in situations where a particular table has been mistakenly changed or deleted. Instead of having to recover the whole database, users could just recover the relevant table from a backup. This would be similar to Recovery Manager (RMAN) Table Point In Time Recovery (PITR) in Oracle.

2.) Log Shipping Subsets of Tables
As you know Log shipping is a solution for high availability and disaster recovery that SQL Server offers. It works at the database level, meaning that it copies the whole database from one server (the primary server) to another (the secondary server).

I have run across several situations where copying the whole database is not needed or wanted. For example, a user might only need to copy a subset of tables for reporting reasons. In such cases, the option to log ship a subset of tables would be very helpful and reduce the data footprint tremendously lots of my databases are over 4 TB, and we only need a subset downstream for reporting.

For example a Subset Restore for Initializing Transactional Replication on VLDB’s.
Initializing transactional replication can be difficult when dealing with very large tables, especially those with over a billion rows.

The snapshot agent, which is in charge of initializing the replication by generating a snapshot of the published database objects and data, does have trouble with such large tables. This can cause performance issues and long initialization times.

One possible solution to this problem is the addition of a subset initialization restore feature. This would allow users to restore only the necessary tables for publications, rather than the entire database. By using subset initialization backup instead of the snapshot agent would make the process more efficient.

Chris

This post was more targeted at system administrators, not DBAs. Thank you for commenting!

It sounds like you installed SQL Server on Windows. Did you use Parallels?

Which version of SQL Server did you install using Docker Desktop?

I was able to get Microsoft SQL installed on my M1 MacBook Pro utilizing Microsoft SQL 2014 (32 bit). I am not an SQL expert. I have two windows-based programs that I have to utilize for my construction company, which rely on Microsoft SQL to work. After installing SQL 2014 (32) bit, both programs ran without any issues.

Thanks Jeff. I hear where you’re coming from, and life has quite a different perspective now that I’m inside the belly of the beast.

I’ll also say that it wouldn’t take much to change my mind but Microsoft has been of no help even as 2022 is less than the horizon away from going public. Having recently to have to work with UNIX TimeStamps at the ms level has only added to the exasperation I feel. What on Earth was Microsoft thinking when they came out with the DATEDIFF_BIG() function without also producing a DATEADD_BIG() function? Further, it’s 2022… why is there no DURATION() Function? It’s not like people haven’t needed one since SQL Server and Sybase first hit the streets.

Oh, yeah… I know all the workarounds. My point is, it IS 2022 and these types of problems have existed in the world of relational databases for decades. We shouldn’t need to do such workarounds in this day and age.

Anyway, let me take this as another opportunity to say “Thank You” again, Randolph, for all of the great articles, presentations, and discoveries you’ve done and made in the past and continue to do. You’re definitely one of the “greats”.

From what I recall of this, yes.