After searching on internet i came across a DMV(Dynamic Management View) provided in SQL Server. This view has almost every detail of a single process executing in SQL Server.

DMV – sys.dm_exec_requests

Following script returned my desired result of percentage completed of my backup job:

SELECT Session_Id, Reads, Writes, Cpu_Time, Logical_Reads, Total_Elapsed_Time,

Blocking_Session_Id, Percent_Complete, Command,

(select text from sys.dm_exec_sql_text(sql_handle)) as Text FROM

sys.dm_exec_requests(nolock) WHERE session_id = 90

Hope this helps.

While searching across internet, i came across a script that will list all the tables in my database and also show how many indexes are created/applied on those table wither clustered or non clustered.

Here’s the script:

with cte as
(
select
table_name = o.name,  �
o.[object_id],
i.index_id,
i.type,
i.type_desc
from
sys.indexes i
inner join
sys.objects o on i.[object_id] = o.[object_id]
where
o.type in (‘U’)
and
o.is_ms_shipped = 0 and i.is_disabled = 0  and i.is_hypothetical = 0
and
i.type <= 2
), cte2 as
(
select
*
from
cte c
pivot
(count(type) for type_desc in ([HEAP], [CLUSTERED], [NONCLUSTERED])) pv
)
select
c2.table_name,
[rows] = max(p.rows),
is_heap = sum([HEAP]),
is_clustered = sum([CLUSTERED]),
num_of_nonclustered = sum([NONCLUSTERED])
from
cte2 c2
inner join
sys.partitions p on c2.[object_id] = p.[object_id] and c2.index_id = p.index_id
group by
table_name

More details can be found here

You need to know every single path from where this procedure is initiating before you can actually remove it from production. Following are some ways to determine the usage of a procedure in SQL Server.

1. Set up a trace and filter through SQL Server profiler service on procedure name and ID.
2. Another way is to regularly check procedure plan cache to see if there is a cached plan for the procedure.
3. Alternatively you can use a 3rd party audit software to retrieve procedure executions. (Most of these soft wares use tracing at the back end)\

SQL Server permissions can be granted to on an object level (schema, database, database objects). In newer versions of SQL Server permissions can be given to user at a more granular level.

To retrieve all the permissions granted to a specific user SQL server has a function named: fn_my_permission.  This function is only accessible to system administrator. e.g

following query will retrieve all the permissions on server.

select * From fn_my_permissions(NULL, NULL) 

following query retrieve all the permissions on a database:

select * From fn_my_permissions(NULL, ‘database’)

following query retrieve all the permissions on a dbo schema:

select * From fn_my_permissions(’dbo’, ’schema’)

If underline I/O architecture system is working properly then every time SQL Server do some transaction (Read/Write) it can do it without waiting. But if load on the system is up, then SQL transaction have to wait for their turns for processing. This can significantly reduce SQL Server performance. There is a much greater issue when you are not in charge of the underlying storage system. For that the main thing is to optimize the queries running by SQL Server.

Following are some tip to monitor and increase I/O performance of SQL Server.

Queries using maximum I/O.

This query will return top 25 queries that were the slowest in processing.

SELECT TOP 25
    q.[text],
    (total_logical_reads/execution_count) AS avg_logical_reads,
    (total_logical_writes/execution_count) AS avg_logical_writes,
    (total_physical_reads/execution_count) AS avg_phys_reads,
     Execution_count
FROM sys.dm_exec_query_stats
    cross apply sys.dm_exec_sql_text(plan_handle) AS q
ORDER BY
 (total_logical_reads + total_logical_writes) DESC

Check which queries can be optimized and update them. Execute the above query frequently to check queries that can potentially create I/O bottleneck on system.

Reading un necessary Data.

When you are retrieving data, which is not going to be used than you are also overusing your I/O performance. One great example of this type of query is:

SELECT * FROM [Table]

Always retrieve only those columns that are going to be used. In cases where you want to get all the columns than specifically write all column names on your select clause.

Also use a WHERE clause where applicable because it will filter out rows that will not be used.

Create Covered Indexes

Once you have optimized your queries by using explicit column names and appropriate WHERE clause filtration of records, you can now focus on creating non-clustered covered index for the queries that have excessive read I/O. Covered indexes contain all columns as a part of index that are being used in SQL WHERE clause. You can also determine what columns are in need to be indexed by examining SQL execution plan of the query.