Department of Computer Science

DAM
Semester project
Class BSIT-7A

Submitted by Submitted TO
Hussain Ali Bukhari Sir Junaid Nasir
Contents
Database Model in Normalized format....................................................................................................2
Power BI installation.................................................................................................................................2
Connection of Power BI with SQL server................................................................................................6
Allocation .mdf and .ldf files.....................................................................................................................9
Permissions in Data base.........................................................................................................................10
Restrict the user.......................................................................................................................................13
Backup and Recovery of database..........................................................................................................17
Restore the database................................................................................................................................20
Disaster recovery in sql...........................................................................................................................23
Execution plan and tuning......................................................................................................................24
Recovery from locking............................................................................................................................25
Trigger Based Email Utility........................................................................................................................28
Database Model in Normalized format

Power BI installation
Connection of Power BI with SQL server
First click on get data
And then click on sql server as show in figure
Allocation .mdf and .ldf files
Permissions in Data base
Restrict the user
Backup and Recovery of database
Restore the database
Disaster recovery in sql
Here are some steps to consider when creating a disaster recovery plan for a SQL database:

 Identify the critical systems and data that need to be recovered in the event of a disaster. This
includes the database servers, networking equipment, and any other systems that are essential for
the operation of the business.

 Determine the recovery point objective (RPO) and recovery time objective (RTO) for each
critical system and data set. The RPO is the maximum amount of data that can be lost before it
becomes detrimental to the business, while the RTO is the amount of time it takes to recover the
system and data to a usable state.
  Develop a plan for backing up the database and critical data on a regular basis. This should
include both onsite and offsite backups to protect against the loss of data due to a disaster.

 Test the disaster recovery plan regularly to ensure that it is effective and up to date. This includes
conducting regular drills to test the backup and recovery procedures, as well as verifying that the
backups are viable and can be restored successfully.

 Review and update the disaster recovery plan on a regular basis to ensure that it remains relevant
and effective. This should include updating the plan to reflect any changes to the database or
critical systems, as well as incorporating any lessons learned from past disasters

Execution plan and tuning

To view the execution plan for a query in SQL Server Management Studio (SSMS), you can follow these
steps:

 Open SSMS and connect to the SQL Server instance that contains the database you want to
query.
 Open a new Query Window and write the query you want to execute.
 Before executing the query, click the "Include Actual Execution Plan" button in the toolbar (it
looks like a little server with a "X" on it). This will tell SQL Server to generate an execution plan
for the query, but not actually execute the query.
 Execute the query by clicking the "Execute" button in the toolbar (it looks like a red exclamation
point).
 After the query finishes executing, the execution plan will be displayed in a separate tab in the
Query Window. You can click on the different operators in the execution plan to see more details
about each step in the query.

To optimize a query using the execution plan, you can look for bottlenecks or inefficiencies in the plan
and try to address them. Some common techniques for query optimization include:

 Indexing: Creating appropriate indexes on the tables referenced in the query can significantly
improve performance.
 Rewriting the query: Sometimes, simply changing the way the query is written can improve its
performance.
 Updating statistics: Out-of-date statistics can lead to inefficient execution plans.
 Hardware upgrades: Adding more memory or faster processors can improve overall performance.
 Partitioning: Partitioning large tables can improve query performance on large datasets.
It's important to note that the specific optimization techniques that are most effective will depend on the
specific characteristics of your database and the query you are trying to optimize.

Recovery from locking

1
2 CREATE DATABASE LockLogging;
3 GO
4 USE LockLogging;
GO
5
 
6 CREATE TABLE LockLogTest (c1 INT, c2 INT, c3 VARCHAR (MAX));
7 GO
8 EXEC sp_tableoption 'LockLogtest', 'large value types out of row', 'on';
9 GO
10  
11 INSERT INTO LockLogTest VALUES (1, 1, 'a');
GO
12
 
13 ALTER DATABASE LockLogging SET RECOVERY SIMPLE;
14 GO
15 CHECKPOINT;
16 GO
17

Now let’s try the first operation – a simple insert – and look at the log records
using fn_dblog (and I’m skipping the checkpoint log records):

?
1 INSERT INTO LockLogTest VALUES (2, 2, 'b');
2 GO
3 SELECT [Operation], [Context], [Page ID], [Slot ID], [Number of Locks] AS Locks, [Lock Information]
4 FROM fn_dblog (NULL, NULL);
GO
5
?
Operation        Context       Page ID        Slot ID  Locks Lock Information
---------------- ------------- -------------- -------- ----- -------------------------------------------------------------------------------------------------------
LOP_BEGIN_XACT   LCX_NULL      NULL           NULL     NULL  NULL
LOP_INSERT_ROWS  LCX_TEXT_MIX  0001:00000098  1        2     ACQUIRE_LOCK_IX PAGE: 18:1:152; ACQUIRE_LOCK_X
LOP_INSERT_ROWS  LCX_HEAP      0001:0000009a  1        3     ACQUIRE_LOCK_IX OBJECT: 18:2073058421:0;ACQUIRE_LO
LOP_COMMIT_XACT  LCX_NULL      NULL           NULL     NULL  NULL

We can see page IX and row X locks for the LOB value being inserted into the text
page, plus table IX, page IX, and row X locks for the data record being inserted into
the heap. The lock resources break out as follows:

 18:1:152 is page 152 in file 1 of database ID 18

 18:1:152:1 is slot 1 on page 152 in file 1 of database ID 18
  18:2073058421:0 is object ID 2073058421 (the object ID of the table
LockLogTest) in database ID 18

Notice also the LOP_BEGIN_XACT and LOP_COMMIT_XACT log records – even

though I didn’t do an explicit transaction, SQL Server has to start one internally for
me so that there’s a boundary for where to rollback if something goes wrong during
the operation.

And now an update operation (with a checkpoint first to clear out the log):

?
1 CHECKPOINT;
2 GO
3 UPDATE LockLogTest SET c1 = 3;
4 GO
5 SELECT [Operation], [Context], [Page ID], [Slot ID], [Number of Locks] AS Locks, [Lock Information]
FROM fn_dblog (NULL, NULL);
6
GO
7
?
Operation        Context       Page ID        Slot ID  Locks Lock Information
---------------- ------------- -------------- -------- ----- ----------------------------------------------------------------------------
LOP_BEGIN_XACT   LCX_NULL      NULL           NULL     NULL  NULL
LOP_MODIFY_ROW   LCX_HEAP      0001:0000009a  0        3     ACQUIRE_LOCK_IX OBJECT: 18:207305
LOP_MODIFY_ROW   LCX_HEAP      0001:0000009a  1        3     ACQUIRE_LOCK_IX OBJECT: 18:207305
LOP_COMMIT_XACT  LCX_NULL      NULL           NULL     NULL  NULL

Just as we expected – a table IX lock, a page IX lock, and two row X locks on that page.

Now, what about something more complicated like a TRUNCATE TABLE? Have you heard the
myth about it not being logged? Right – it’s a myth:

?
1 CHECKPOINT;
2 GO
3 TRUNCATE TABLE LockLogTest;
4 GO
5 SELECT [Operation], [Context], [Page ID], [Slot ID], [Number of Locks] AS Locks, [Lock Information]
6 FROM fn_dblog (NULL, NULL);
7 GO
?
Operation        Context       Page ID        Slot ID  Locks Lock Information
---------------- ------------- -------------- -------- ----- ----------------------------------------------------------------------------
LOP_BEGIN_XACT   LCX_NULL      NULL           NULL     NULL  NULL
LOP_LOCK_XACT    LCX_NULL      NULL           NULL     1     ACQUIRE_LOCK_SCH_M OBJECT: 18:20
LOP_MODIFY_ROW   LCX_IAM       0001:0000009b  0        1     ACQUIRE_LOCK_X RID: 18:1:155:0
LOP_MODIFY_ROW   LCX_PFS       0001:00000001  0        1     ACQUIRE_LOCK_X PAGE: 18:1:154
LOP_MODIFY_ROW   LCX_PFS       0001:00000001  0        1     ACQUIRE_LOCK_X PAGE: 18:1:155
LOP_MODIFY_ROW   LCX_IAM       0001:00000099  0        1     ACQUIRE_LOCK_X RID: 18:1:153:0
LOP_MODIFY_ROW   LCX_PFS       0001:00000001  0        1     ACQUIRE_LOCK_X PAGE: 18:1:152
LOP_MODIFY_ROW   LCX_PFS       0001:00000001  0        1     ACQUIRE_LOCK_X PAGE: 18:1:153
LOP_SET_BITS     LCX_SGAM      0001:00000003  1        NULL  NULL
LOP_SET_BITS     LCX_GAM       0001:00000002  1        NULL  NULL
LOP_COUNT_DELTA  LCX_CLUSTERED 0001:00000014  89       NULL  NULL
LOP_COUNT_DELTA  LCX_CLUSTERED 0001:00000011  78       NULL  NULL
LOP_COUNT_DELTA  LCX_CLUSTERED 0001:00000014  90       NULL  NULL
LOP_COUNT_DELTA  LCX_CLUSTERED 0001:00000041  164      NULL  NULL
LOP_COUNT_DELTA  LCX_CLUSTERED 0001:00000041  165      NULL  NULL
LOP_COUNT_DELTA  LCX_CLUSTERED 0001:00000041  166      NULL  NULL
LOP_HOBT_DDL     LCX_NULL      NULL           NULL     NULL  NULL
LOP_MODIFY_ROW   LCX_CLUSTERED 0001:00000014  89       2     ACQUIRE_LOCK_IX OBJECT: 18:7
LOP_HOBT_DDL     LCX_NULL      NULL           NULL     NULL  NULL
LOP_MODIFY_ROW   LCX_CLUSTERED 0001:00000014  90       2     ACQUIRE_LOCK_IX OBJECT: 18:7
LOP_MODIFY_ROW   LCX_CLUSTERED 0001:00000011  78       2     ACQUIRE_LOCK_IX OBJECT: 18:5
LOP_COMMIT_XACT  LCX_NULL      NULL           NULL     NULL  NULL

Lots of logging and lots of locks. If you look at the Context column, you’ll see that the operation
is modifying allocation bitmaps (LCX_IAM, LCX_PFS, LCX_SGAM, LCX_GAM) but taking
locks on the table pages, not on the allocation bitmaps themselves – they’re only ever latched (an
internal, much lighter-weight, synchronization mechanism). This is done as the pages comprising
the table are deallocated – this is all done because the table’s small enough that the Storage
Engine chooses to deallocate all the storage immediately, instead of pushing it all onto the task
queue for the deferred drop background task. See my previous post Search Engine Q&A #10:
When are pages from a truncated table reused? which discusses this too.

There are no actual row operations performed on the table itself. The only table row operations
are down at the bottom on table with object IDs 7 and 5 (sys.sysallocunits and sys.sysrowsets,
respectively) to update the page counts, first IAM, and first page entries for the table.

So – hopefully this has been useful to you. In the next post in the series, I’ll discuss
compensation log records and how rollback operations work.

PS Send me an email or put in a comment if there’s something in particular about the log (or log
records) you’d like to see explained.
Trigger Based Email Utility