You are on page 1of 2

What are the plans present in SQL server maintenance plan?

Maintenance plans can be created to perform the following tasks: Reorganize the data on the data and index pages by rebuilding indexes with a new fill factor. Compress data files by removing empty database pages. Update index statistics to make sure the query optimizer has current information about the distribution of data values in the tables. Perform internal consistency checks of the data and data pages within the database to make sure that a system or software problem has not damaged data. Back up the database and transaction log files. Run SQL Server Agent jobs. This can be used to create jobs that perform a variety of actions and the maintenance plans to run those jobs.

Enbling CLR Integration sp_configure 'clr enabled', 1 GO RECONFIGURE GO OR

Programs->Microsoft SQL Server ->Config tools->Surface Area Config Mgr


what is the statement used to delete mails after 60 days sysmail_delete_mailitems_sp DMV purpose: which shows performance metrics : sys.dm_os_performance_counters which shows which file is being accessed : sys.dm_io_virtual_file_stats which measures the memory required for a query to run : Which option should be turned on so that it can avoid users from accessing the database when the query is executing? restricted user isolation level READ UNCOMMITTED is the least restrictive isolation level because it ignores locks placed by other transactions. Transactions executing under READ UNCOMMITTED can read modified data values that have not yet been committed by other transactions; these are called "dirty" reads. READ COMMITTED is the default isolation level for SQL Server. It prevents dirty reads by specifying that statements cannot read data values that have been modified but not yet committed by other transactions. Other transactions can still modify, insert, or delete data between executions of individual statements within the current transaction, resulting in nonrepeatable reads, or "phantom" data. REPEATABLE READ is a more restrictive isolation level than READ COMMITTED. It encompasses READ COMMITTED and additionally specifies that no other transactions can modify or delete data that has been read by the current transaction until the current transaction commits. Concurrency is lower than for READ COMMITTED because shared locks on read data are held for the duration of the transaction instead of being released at the end of each statement. SERIALIZABLE is the most restrictive isolation level, because it locks entire ranges of keys and holds the locks until the transaction is complete. It encompasses REPEATABLE READ and adds the restriction that other transactions cannot insert new rows into ranges that have been read by the transaction until the transaction is complete.

SNAPSHOT isolation specifies that data read within a transaction will never reflect changes made by other simultaneous transactions. The transaction uses the data row versions that exist when the transaction begins. No locks are placed on the data when it is read, so SNAPSHOT transactions do not block other transactions from writing data. Transactions that write data do not block snapshot transactions from reading data. You need to enable snapshot isolation by setting the ALLOW_SNAPSHOT_ISOLATION database option in order to use it. The READ_COMMITTED_SNAPSHOT database option determines the behavior of the default READ COMMITTED isolation level when snapshot isolation is enabled in a database. If you do not explicitly specify READ_COMMITTED_SNAPSHOT ON, READ COMMITTED is applied to all implicit transactions. This produces the

same behavior as setting READ_COMMITTED_SNAPSHOT OFF (the default). When READ_COMMITTED_SNAPSHOT OFF is in effect, the Database Engine uses shared locks to enforce the default isolation level. If you set the READ_COMMITTED_SNAPSHOT database option to ON, the database engine uses row versioning and snapshot isolation as the default, instead of using locks to protect the data. what 3 statements are to be executed in sequence so that u put the log files in L drive and data files in D drive. use master go alter database X modify file (name=tempdev, filename=D:\MSSQL\DATA\XDB.MDF, size = 1mb) go alter database X modify file (name=templog, filename=L:\MSSQL\LOGS\Xlog.LDF, size = 1mb) go restart the SQL Server. Julia is able to login in to server. she forgets her password and after recollecting her password she still unable to login. So what should be done so that she can login back in to it. options given are unlock can; (with password UNLOCK or policy OFF and ON) enable CAN, maybe user was disabled after x tries? U created a partition function xxx with values in to it. Now u have to create a partition scheme so that it copies the data in to a SECONDARY file group. CREATE PARTITION SCHEME SEC_FG AS PARTITION FUNC_FG ALL TO ( SECONDARY );