This is the UTC for Eastern time zone for North America based on current eastern time.

SELECT
t.NAME AS TableName,
p.rows AS TableRowCounts,
CONVERT(DECIMAL,SUM(a.total_pages)) * 8 / 1024 AS TotalSpaceMB,
CONVERT(DECIMAL,SUM(a.total_pages)) * 8 / 1024 /1024 AS TotalSpaceGB,
SUM(a.used_pages) * 8 / 1024 AS UsedSpaceMB ,
SUM(a.used_pages) * 8 / 1024 / 1024 AS UsedSpaceGB
FROM
DatabaseName.sys.tables t
INNER JOIN
DatabaseName.sys.indexes i ON t.OBJECT_ID = i.object_id
INNER JOIN
DatabaseName.sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id
INNER JOIN
DatabaseName.sys.allocation_units a ON p.partition_id = a.container_id
LEFT OUTER JOIN
DatabaseName.sys.schemas s ON t.schema_id = s.schema_id
WHERE
t.is_ms_shipped = 0
AND i.OBJECT_ID > 255
GROUP BY
t.Name, s.Name, p.Rows
ORDER BY
UsedSpaceGB DESC, t.Name

The correct query for the above example is:

EXEC msdb.dbo.sp_send_dbmail
@profile_name ='dbMail',
@recipients = 'dharmyog.com@gmail.com',
@subject ='Test Email',
@body ='Test Email',
@query=' select * from [dbo].[vwEmployees] Where EmployeeAge = 25',
@attach_query_result_as_file = 1;

EXEC msdb.dbo.sp_send_dbmail
@profile_name ='dbMail',
@recipients = 'dharmyog.com@gmail.com',
@subject ='Test Email',
@body ='Test Email',
@query=' select * from EmployeeDB.dbo.vwEmployees Where EmployeeAge = 25',
@attach_query_result_as_file = 1;

This way the stored procedure will execute under the msdb context and the query will execute because the database hierarchy is referenced. So the database name has to be entered in the query.

select * from sys.time_zone_info
order by name

Select L.NAME DBName,R.percent_complete as [Progress%]
FROM Master.dbo.sysdatabases L Left join sys.dm_exec_requests R on L.DBID=R.Database_ID
WHERE percent_complete > 0
raiserror('',0,1) with nowait
waitfor delay '00:00:10'
GO 15

This is the path for if you have have SSDT version installed for VS2017

C:\Users\AumTechHubUser1\Documents\Visual Studio 2017\Backup Files\Solution1

SELECT
L.NAME DBName,
R.percent_complete as [Progress%]
FROM Master.dbo.sysdatabases L Left join sys.dm_exec_requests R on L.DBID=R.Database_ID
WHERE R.Command LIKE '%BACKUP%'

Or you can change the where clause and use the following

SELECT
L.NAME DBName,
R.percent_complete as [Progress%]
FROM Master.dbo.sysdatabases L Left join sys.dm_exec_requests R on L.DBID=R.Database_ID
WHERE percent_complete > 0

If no backups are running then the query will return no data.

select * from sys.objects where create_date > dateadd(D, -1, getdate())

This second query tells us if there were any database objects modified within the last 24 hours. You can modify the DATEADD parameters to get a larger time span.

select * from sys.objects where modify_date > dateadd(D, -1, getdate())

Production server is PD-AumTech_PC1

The staging reporting server is SG-AumTech_PC1

Database name: EmployeeDB

We setup the log shipping so that reporting server gets daily changes over from production  server once a day so we have previous days data on reporting server by 8am on staging server.

In order to do this we looked at replication and SQL backups but log shipping in the end was the best option for this problem.

Currently the following jobs are created and steps below are sequentially setup for the log shipping solution.

Important Note:  The Employee database on production has to be in full recovery model. The very first time you must make a backup of the EmployeeDatabase from production environment. Then restore it to the Staging server using that same full backup. The EmployeeDatabase must be restored with “standby mode with recovery” option in standby/read-only mode on the staging server as only changes in TRN log files coming from production server will be applied on a daily basis. Also be sure to run SQL Sever and SQL server agent are running under a network domain account. The account must have access to the file share where transaction files are stored. If both servers are running under different network accounts then make sure both accounts have access to the network file share path.

1. Using the wizard for log shipping the following jobs will be created, The log shipping jobs on PD-AumTech_PC1 is “LSBackup_EmployeeDB”. This job will create a transaction log file 7am in this network path “\\AumTechLSNetworkShare\DBBackupFolder”. Both the staging server and production server must have access to this network path.

2. The log shipping jobs on SG-AumTech_PC1 is “LSCopy_EmployeeDatabase”. This job will copy the transaction log file (from earlier 7am on production server) and run at 715am and copy the trn file to local path on the staging server machine “\\SG-AumTech_PC1\c$\SQL_LogFiles”

3. The log shipping job on SG-AumTech_PC1 is “LSRestore_EmployeeDatabase”. This job will apply the transactions trn file from c:\SQL_LogFiles to the database on staging server and update the database with all data from the previous trn file 24 hours prior.

These 3 jobs continue to run daily and update data on the staging server daily.

Additional Notes: If  for any reason the log shipping stops working. Then best way to reset the entire process is to do the following.

1. Check if the service on the staging server is running the sql server agent and it has access to the network path where the trn files are stored.

2. If for any reason you need to redo the setup then take a full backup of the database WITHOUT the COPY_ONLY command. Then restore the database to staging server. Keep the same jobs and schedule. You can manually do the following steps to make sure the setup is still working.

A. Run The logshipping jobs on PD-AumTech_PC1 is “LSBackup_EmployeeDatabase”. This job will create a transaction log file in this path “\\AumTechLSNetworkShare\DBBackupFolder”

B. Next run the logshipping jobs on SG-AumTech_PC1 is “LSCopy_EmployeeDatabase”. This job will copy the transaction log file and copy the trn file to local path on the machine”\\SG-AumTech_PC1\c$\SQL_LogFiles” (c:\SQL_LogFiles)

C. Next run the log shipping job on SG-AumTech_PC1 is “LSRestore_EmployeeDatabase”. This job will apply the transactions trn file from c:\SQL_LogFiles to the database and update the database with all data from the previous TRN file 24 hours prior.

Be sure to thinking about how your production database backups should be setup and when the database logs should be shrinked for disk space. At which point you may have to follow the steps mentioned in the additional steps listed above.

CREATE TABLE #TableRowCounts
(
TableName varchar(150),
TotalRows int
)

EXEC sp_MSForEachTable @command1=’INSERT #TableRowCounts (TableName, TotalRows) SELECT ”?”, COUNT(*) FROM ?’

SELECT TableName, TotalRows FROM #TableRowCounts ORDER BY TableName, TotalRows DESC

DROP TABLE #TableRowCounts

More on sp_MSForEachTable