SQL Server practical experience and tips [1]

(1) pending operations

When installing the SQL or SP patch, the system prompts that a pending installation operation is required. Restart is often useless. solution:

To HKEY_LOCAL_MACHINE/system/CurrentControlSet/control/Session Manager
Delete pendingfilerenameoperations

(2) shrinking the database

-- Re-Indexing
DBCC reindex
DBCC indexdefrag
-- Shrink data and logs
DBCC shrinkdb
DBCC shrinkfile
 

(3) compressing the database

DBCC shrinkdatabase (dbname)
 

(4) Transfer the database to a new user with existing User Permissions

Exec sp_change_users_login 'Update _ one', 'newname', 'oldname'
Go
 

(5) Check the backup set

Restore verifyonly from disk = 'e:/dvbbs. Bak'
 

(6) database Restoration

Alter database [dvbbs] Set single_user
Go
DBCC checkdb ('dvbbs ', repair_allow_data_loss) with tablock
Go
Alter database [dvbbs] Set multi_user
Go

-- Checkdb has three parameters:

-- Repair_allow_data_loss
 

-- Execute all the repairs completed by repair_rebuild, including allocating and unassigning rows and pages to correct the allocation errors, structure row or page errors, and deleting corrupted text objects. These fixes may cause some data loss. The repair operation can be completed under the user transaction to allow the user to roll back the changes. If the rollback is fixed, the database will still contain errors and the backup should be restored. If an error fix is missing due to the severity of the severity level provided, it will omit any fix that depends on the fix. After the restoration, back up the database.

-- Repair_fast Performs small and time-consuming repair operations, such as fixing the additional keys in non-clustered indexes. These repairs can be completed quickly without the risk of data loss.

-- Repair_rebuild: execute all the repairs completed by repair_fast, including repairs that require a long period of time (such as re-indexing ). There is no risk of data loss when performing these repairs.

-- DBCC checkdb ('dvbbs ') with no_infomsgs, physical_only
 

Two Methods for clearing SQL server logs
During usage, we often encounter very large database logs. Here we introduce two solutions ......

Method 1

In general, the contraction of the SQL database does not greatly reduce the size of the database. Its main function is to shrink the log size. This operation should be performed regularly to avoid excessive database logs.

1. Set database mode to simple mode: Open the SQL Enterprise Manager, in the root directory of the console, open Microsoft SQL Server --> SQL Server group --> double-click your server --> double-click to open the database directory --> select your database name (such as the Forum database) forum) --> then right-click and select Properties --> Select Options --> select "simple" in the fault recovery mode, and click OK to save.

2. Right-click the current database to view the shrinking database in all tasks. Generally, the default settings in the database do not need to be adjusted. Click OK directly.

3. After shrinking the database, we recommend that you set your database attributes to the standard mode. The operation method is the same as the first one, because logs are often an important basis for restoring the database in case of exceptions.

Method 2

Set nocount on
Declare @ logicalfilename sysname,
@ Maxminutes int,
@ Newsize int

Use tablename -- Name of the database to be operated
Select @ logicalfilename = 'tablename _ log', -- Log File Name
@ Maxminutes = 10, -- limit on time allowed to wrap log.
@ Newsize = 1 -- the size of the log file you want to set (m)
 

 

-- Setup/initialize
Declare @ originalsize int
Select @ originalsize = size
From sysfiles
Where name = @ logicalfilename
Select 'original size of '+ db_name () + 'Log is' +
Convert (varchar (30), @ originalsize) + '8 K pages or '+
Convert (varchar (30), (@ originalsize * 8/1024) + 'mb'
From sysfiles
Where name = @ logicalfilename
Create Table dummytrans
(Dummycolumn char (8000) not null)
 

 

Declare @ counter int,
@ Starttime datetime,
@ Trunclog varchar (255)
Select @ starttime = getdate (),
@ Trunclog = 'backup log' + db_name () + 'with truncate_only'

DBCC shrinkfile (@ logicalfilename, @ newsize)
Exec (@ trunclog)
-- Wrap the log if necessary.
While @ maxminutes> datediff (MI, @ starttime, getdate () -- time has not expired
And @ originalsize = (select size from sysfiles where name = @ logicalfilename)
And (@ originalsize * 8/1024)> @ newsize
Begin -- outer loop.
Select @ counter = 0
While (@ counter <@ originalsize/16) and (@ counter< 50000 ))
Begin -- Update
Insert dummytrans values ('fill log ')
Delete dummytrans
Select @ counter = @ counter + 1
End
Exec (@ trunclog)
End
Select 'final size of '+ db_name () + 'Log is' +
Convert (varchar (30), size) + '8 K pages or '+
Convert (varchar (30), (size * 8/1024) + 'mb'
From sysfiles
Where name = @ logicalfilename
Drop table dummytrans
Set nocount off