sqlserver 日志傳送 實戰(zhàn)

liyihongcug

現在 問題
下面的方法是不過這個方法就是這一次的日志備份會覆蓋上一次的日志備份文件,而我想做到的效果是A服務器上還是保存按時間排列的日志,只是傳送到B服務器的時候能夠讓B隨時還原并保持和A服務器一致呀.？？
（主庫有 充分的日志， 我 在思考能否不在主庫上 作 backup log。 而直接用那些 日志？？）

/*--說明：
    下面的代碼演示了如何利用日志還原功能，將主數據庫中的數據變化及時反饋到備用數據庫中
    備用數據庫的數據可以隨時用于查詢，但不能被更新（備用數據庫只讀）。
--*/

--首先,創(chuàng)建一個演示用的數據庫(主數據庫)
CREATE DATABASE Db_test
ON
( NAME = Db_test_DATA,
      FILENAME = 'c:\Db_test.mdf' )
LOG ON
( NAME = Db_test_LOG,
   FILENAME = 'c:\Db_test.ldf')
GO

--對數據庫進行備份
BACKUP DATABASE Db_test TO DISK='c:\test_data.bak' WITH FORMAT
GO

--把數據庫還原成備用數據庫(演示主數據庫與這個備用數據庫之間的同步)
RESTORE DATABASE Db_test_bak FROM DISK='c:\test_data.bak'
WITH REPLACE,STANDBY='c:\db_test_bak.ldf'
    ,MOVE 'Db_test_DATA' TO 'c:\Db_test_data.mdf'
    ,MOVE 'Db_test_LOG' TO 'c:\Db_test_log.ldf'
GO

--啟動 SQL Agent 服務
EXEC master..xp_cmdshell 'net start sqlserveragent',no_output
GO

--創(chuàng)建主服務器數據訓與備用服務器數據庫之間同步的作業(yè)
DECLARE  @jogid uniqueidentifier
EXEC msdb..sp_add_job
    @job_id = @jogid OUTPUT,
    @job_name = N'數據同步處理'

--創(chuàng)建同步處理步驟
EXEC msdb..sp_add_jobstep
    @job_id = @jogid,
    @step_name = N'數據同步',
    @subsystem = 'TSQL',
    @command = N'
--主數據庫中進行日志備份
BACKUP LOG Db_test TO DISK=''c:\test_log.bak'' WITH FORMAT

--備用數據庫中還原主數據庫的日志備份(應用主數據庫中的最新變化
--實際應該時主數據庫備份與備用數據庫的還原作業(yè)應該分別在主服務器和備用服務器上建立，并且備份文件應該放在主服務器和備用都能訪問的共享目錄中
RESTORE LOG Db_test_bak FROM DISK=''c:\test_log.bak'' WITH STANDBY=''c:\test_log.ldf''',
    @retry_attempts = 5,
    @retry_interval = 5

--創(chuàng)建調度(每分鐘執(zhí)行一次)
EXEC msdb..sp_add_jobschedule
    @job_id = @jogid,
    @name = N'時間安排',
    @freq_type=4,
    @freq_interval=1,
    @freq_subday_type=0x4,
    @freq_subday_interval=1,
    @freq_recurrence_factor=1

-- 添加目標服務器
EXEC msdb.dbo.sp_add_jobserver
    @job_id = @jogid,
    @server_name = N'(local)'
GO

--通過上述處理,主數據庫與備用數據庫之間的同步關系已經設置完成
--下面開始測試是否能實現同步

--在主數據庫中創(chuàng)建一個測試用的表
CREATE TABLE Db_test.dbo.TB_test(ID int)
GO

--等待1分鐘30秒（由于同步的時間間隔設置為1分鐘,所以要延時才能看到效果）
WAITFOR DELAY '00:01:30'
GO

--查詢一下備用數據庫,看看同步是否成功
SELECT * FROM Db_test_bak.dbo.TB_test

/*--結果:
ID         
-----------

（所影響的行數為 0 行）
--*/

--測試成功
GO

--最后刪除所有的測試
DROP DATABASE Db_test,Db_test_bak
EXEC msdb..sp_delete_job @job_name=N'數據同步處理'
GO


/*===========================================================*/

/*--服務器檔機處理說明
    使用這種方式建立的數據庫同步，當主數據庫不可用時（例如，主數據庫損壞或者停機檢修）
    可以使用以下兩種方法使備用數據庫可用。
--*/

--1. 如果主數據庫損壞，無法備份出最新的日志，可以直接使用下面的語句使備用數據庫可讀寫（丟失最近一次日志還原后的所有數據）。
RESTORE LOG Db_test_bak WITH RECOVERY


--2. 如果主數據庫可以備份出最新日志，則可以使用下面的語句。
--先備份主數據庫的最新的事務日志
BACKUP LOG Db_test TO DISK=''c:\test_log.bak'' WITH FORMAT
--再在備用數據庫中恢復最新的事務日志，并且使備用數據庫可讀寫（升級為主數據庫）
RESTORE LOG Db_test_bak FROM DISK='c:\test_log.bak'

liyihongcug

因工作需要,公司數據庫需采用日志傳送+鏡像的方式,此配置方法不需要域,不需要證書驗證,唯一需要的就是兩臺服務器賬號名和密碼相同就Ok,以下為測試步驟:

1.主機和備機上,檢查SQLServer版本號,確認版本號一致;

2.在主機上確認需要鏡像的數據庫恢復模式為完整模式(因為之前數據庫已經做了日志傳送,所以這一步省了);

3.檢查主機和備機的SQLServer服務和Agent服務啟動賬戶是否相同.如果兩臺服務器不在域里面,服務啟動賬戶請使用”.\username”格式(這一步很關鍵,因為測試服務器不在域里,這個地方卡了N久);

4.先在主機上把日志傳送的日志備份作業(yè)禁用;

5. 在主機上對數據庫做一個完整備份和一個日志備份;
BACKUPDATABASEtest_mirTODISK='D:\test_mir.bak'
BACKUPLOGtest_mirTODISK='D:\test_mir.trn'

6.將備份文件拷貝至備機,用完整備份和日志備份進行還原;
RESTORE DATABASE test_mir FROM DISK='D:\test_mir.bak' WITH NORECOVERY
RESTORE LOG test_mir FROM DISK='D:\test_mir.trn' WITH NORECOVERY

7.分別在主機和備機上創(chuàng)建端點;
CREATEENDPOINTEndpoint_test_mirSTATE=STARTED
AS
TCP(LISTENER_PORT=5022,LISTENER_IP=ALL)FOR
DATABASE_MIRRORING(ROLE=PARTNER);

8.   在備機上執(zhí)行
ALTERDATABASE test_mirSETPARTNER='TCP://主機IP:5022';

9. 在主機上執(zhí)行(至此鏡像已經建立完畢)
ALTERDATABASEtest_mirSETPARTNER='TCP://備機IP:5022';
ALTERDATABASEtest_mirSETSAFETYOFF –-高性能異步模式

10. 到日志傳送的目標服務器上手動還原最后備份的日志文件
RESTORELOGtest_mirFROM DISK=N'd:\database_name.trn'WITH FILE=1,STANDBY=N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\ROLLBACK_UNDO_test_mir.BAK', NOUNLOAD, STATS=10

11.在主機上重新啟用日志傳送的日志備份job;

至此已配置完成.



在主機的數據庫里建個表,插入一些數據,然后再分別到鏡像庫和日志傳送庫里檢查,是否同步.

日志傳送得看你設置的調度時間隔,鏡像一般是很快的,在鏡像庫上查的時候得先創(chuàng)建快照才能查哦~~~

liyihongcug

好文章
ost DBAs dread hearing that they need to restore a database to a point in time, especially if the database is a production database. However, knowing how to do this is of the utmost importance for a DBA's skill set. I'll walk you through the steps of how to restore a SQL Server database to a point in time to recover a data table.

The scenario

A coworker calls you in a panic because he accidentally deleted some production data, and he wants you to restore the lost records.

If you are lucky, you have a data auditing system in place, and you can restore these records from an audit table. If you do not have a tool that will read a transaction log so that you can undo transactions, you will likely need to restore the altered database to a certain point in time on the same or separate server than the server hosting the current database instance.

The restoration process

Note that, for the purpose of this article, I am assuming that your database recovery mode is set to FULL.

The first step in the process is to perform a tail-log backup. You want to perform this type of backup before a database restore to ensure that any records that have changed since the last backup are available to be included in the restore process.

Next you should locate where the database backup files are stored on the machine or the network. It may be a good idea to copy these files to your target server if you are going to be restoring the database on a different server. In the backup file location, find the very last full database backup that was completed (these files usually end with the extension .bak); you need to restore this full backup. The script below applies the full backup file to the NewDatabase database:

RESTORE DATABASE NewDatabase
FROM DISK = 'D: \BackupFiles\TestDatabaseFullBackup.bak'
WITH
MOVE 'PreviousDatabase' TO 'D:\DataFiles \TestDatabase.mdf',
MOVE 'PreviousDatabase_log' TO 'D:\DataFiles \TestDatabase_Log.ldf',
NORECOVERY

The code specifies that the location of the full backup file is on your server's D drive and that you are restoring the file to the database named NewDatabase. The statement moves the data file and the log file from the full backup to new files for my TestDatabase database. The last statement in the script, NORECOVERY, is very crucial. The NORECOVERY mode is one of three available options, which are outlined below.

|> NORECOVERY: Tells SQL Server that you are not finished restoring the database and that subsequent restore files will occur. While the database is in this state, the database is not yet available, so no connections are allowed.
|> RECOVERY: Tells SQL Server that you are finished restoring the database, and it is ready to be used. This is the default option, and it is by far the one that is used most often.
|> STANDBY: Tells SQL Server that the current database is not yet ready to be fully recovered and that subsequent log files can be applied to the restore. You can use this option so that connections are available to the restore database if necessary. However, future transaction logs can only be applied to the database if no current connections exist.

Once you restore the full backup using the NORECOVERY option, you can begin applying the transaction log backups or the differential backup.

Differential backup
A differential backup is a backup of any changes to the database that have occurred since the last full database backup. If you have multiple differential backups, you will only need to restore the very last one taken. In this situation, there are no differential backups, so you can move directly to the transaction log backups.

Transaction log backups
A transaction log backup keeps track of all transactions that have occurred since the last transaction log backup; it also allows you to restore your database to a point in time before a database error occurred. Transaction log backups occur in sequence, creating a chain. When restoring a sequence of transaction log backups to a point in time, it is required that the transaction log files are restored in order.

When you use a database maintenance plan to create the transaction log backups, a time indicator is typically included in the transaction log file name. The script below applies three transaction log backups using the NORECOVERY option, and the last statement restores the database to availability to the time frame at the very end of the last transaction log file.

RESTORE LOG NewDatabase
FROM DISK = ''D: \BackupFiles\TestDatabase_TransactionLogBackup1.trn'
WITH NORECOVERY

RESTORE LOG NewDatabase
FROM DISK = ''D: \BackupFiles\ TestDatabase_TransactionLogBackup2.trn'
WITH NORECOVERY

RESTORE LOG NewDatabase
FROM DISK = ''D: \BackupFiles\ TestDatabase_TransactionLogBackup3.trn'
WITH NORECOVERY

RESTORE LOG NewDatabase
FROM DISK = ''D: \BackupFiles\ TestDatabase_TransactionLogBackup4.trn'
WITH RECOVERY

Restoring to a point in time
In the example above, you restore the database to the end of the last transaction log. If you want to recover your database to a specific point in time before the end of the transaction log, you must use the STOPAT option. The script below restores the fourth transaction log in the log sequence to 4:01 PM -- just before the database mishap occurred.

RESTORE LOG NewDatabase
FROM DISK = ''D: \BackupFiles\ TestDatabase_TransactionLogBackup4.trn'
WITH STOPAT = N'6/28/2007 4:01:45 PM', RECOVERY

Now that you have the database restore to a point where you need it to be, it is time to decide how to help the developers in order to make their situation a little bit easier. My suggestion is to copy the table the developers need to a separate table on the server so that you or they can correct the data problem.

Be prepared

Restoring your database to a point in time is one of those things that you never want to have to use, but you need to be able to complete it if necessary. I took an overview approach as to how to restore your SQL Server database using transaction logs for a certain circumstance. It's important to note that companies use different approaches for backing up data, so it is very important to be thoroughly involved in your company's database backup process. Be sure to test restores and restore situations often so that you are ready when a disaster does occur.

liyihongcug

察看輔助數據庫的相關job(LSRestore_Manit_sh-prod)的history,總是呈現下面的錯誤：

先是數十次的Skip:
---------------------------------------------------------------------------------------------------------
Date                4/7/2010 1:20:00 PM
Log                Job History (LSRestore_sh-prod_MANIT)

Step ID                1
Server                SH-SQLBKUP\SH_PROD_BACKUP
Job Name                LSRestore_sh-prod_MANIT
Step Name                Log shipping restore log job step.
Duration                00:00:25
Sql Severity                0
Sql Message ID                0
Operator Emailed               
Operator Net sent               
Operator Paged               
Retries Attempted                0

Message
2010-04-07 13:20:25.52        Skipped log backup file. Secondary DB: 'MANIT_Report', File: 'e:\manit_trans_log\MANIT_20100406014500.trn'

上面每次skip掉的trn文件都不同，就是嘗試每一個trn文件，如果不能restore，就skip掉。
最后是Can not find a appropriate log file:
---------------------------------------------------------------------------------------------------------
Date                4/7/2010 1:20:00 PM
Log                Job History (LSRestore_sh-prod_MANIT)

Step ID                1
Server                SH-SQLBKUP\SH_PROD_BACKUP
Job Name                LSRestore_sh-prod_MANIT
Step Name                Log shipping restore log job step.
Duration                00:00:25
Sql Severity                0
Sql Message ID                0
Operator Emailed               
Operator Net sent               
Operator Paged               
Retries Attempted                0

Message
2010-04-07 13:20:25.61        Skipped log backup file. Secondary DB: 'MANIT_Report', File: 'e:\manit_trans_log\MANIT_20100406014000.trn'
2010-04-07 13:20:25.61        *** Error: Could not find a log backup file that could be applied to secondary database 'MANIT_Report'.(Microsoft.SqlServer.Management.LogShipping) ***
2010-04-07 13:20:25.61        Deleting old log backup files. Primary Database: 'MANIT'
2010-04-07 13:20:25.61        The restore operation completed with errors. Secondary ID: '09f6796f-f6f2-448d-b4af


lijianger
Sorry, 可能是我的表述使你產生了誤解，我所說的skip是在每次restore時，都會發(fā)生的，因為在secondary 端的copy文件夾下有很多的trn文件，所以LSRestore job會找每一個trn, 如果不能restore就skip, 直到都找遍了，最后就報restore failed. 導出的LSRestore History如下：（需要從下往上看）
Date,Source,Severity,Step ID,Server,Job Name,Step Name,Notifications,Message,Duration,Sql Severity,Sql Message ID,Operator Emailed,Operator Net sent,Operator Paged,Retries Attempted
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Error,0,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,(Job outcome),,The job failed.  The Job was invoked by Schedule 24 (DefaultRestoreJobSchedule).  The last step to run was step 1 (Log shipping restore log job step.).,00:00:26,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Error,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,Executed as user: SH-SQLBKUP\SYSTEM. The step failed.,00:00:26,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:25.80        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406014000.trn'<nl/>2010-04-07 13:00:25.80        *** Error: Could not find a log backup file that could be applied to secondary database 'MANIT_Report'.(Microsoft.SqlServer.Management.LogShipping) ***<nl/>2010-04-07 13:00:25.80        Deleting old log backup files. Primary Database: 'MANIT'<nl/>2010-04-07 13:00:25.81        The restore operation completed with errors. Secondary ID: '09f6796f-f6f2-448d-b4af-60fffb31586d'<nl/>2010-04-07 13:00:25.81        ----- END OF TRANSACTION LOG RESTORE     -----<nl/><nl/>Exit Status: 1 (Error),00:00:25,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:25.71        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406014500.trn',00:00:25,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:25.60        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406015000.trn',00:00:25,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:25.50        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406015500.trn',00:00:25,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:25.42        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406020000.trn',00:00:25,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:25.31        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406020500.trn',00:00:25,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:25.13        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406021500.trn'<nl/>2010-04-07 13:00:25.22        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406021000.trn',00:00:25,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:25.03        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406022000.trn',00:00:25,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:24.94        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406022500.trn',00:00:25,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:24.83        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406023000.trn',00:00:24,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:24.74        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406023501.trn',00:00:24,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:24.64        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406024000.trn',00:00:24,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:24.55        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406024500.trn',00:00:24,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:24.36        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406025500.trn'<nl/>2010-04-07 13:00:24.46        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406025000.trn',00:00:24,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:24.27        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406030000.trn',00:00:24,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:24.17        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406030500.trn',00:00:24,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:24.08        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406031000.trn',00:00:24,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:24.00        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406031500.trn',00:00:24,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:23.91        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406032000.trn',00:00:23,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:23.83        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406032500.trn',00:00:23,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:23.72        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406033000.trn',00:00:23,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:23.63        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406033500.trn',00:00:23,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:23.53        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406034000.trn',00:00:23,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:23.38        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406035000.trn'<nl/>2010-04-07 13:00:23.46        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406034500.trn',00:00:23,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:23.28        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406035501.trn',00:00:23,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:23.21        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406040000.trn',00:00:23,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:23.03        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406041000.trn'<nl/>2010-04-07 13:00:23.11        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406040500.trn',00:00:23,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:22.96        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406041500.trn',00:00:23,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:22.86        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406042000.trn',00:00:22,0,0,,,,0
04/07/2010 13:00:00,LSRestore_sh-prod_MANIT,Unknown,1,SH-SQLBKUP\SH_PROD_BACKUP,LSRestore_sh-prod_MANIT,Log shipping restore log job step.,,2010-04-07 13:00:22.77        Skipped log backup file. Secondary DB: 'MANIT_Report'<c/> File: 'e:\manit_trans_log\MANIT_20100406042500.trn',00:00:22,0,0,,,,0

liyihongcug

最好的
日志轉移是這樣一種處理過程，它能將某一數據庫中的事務日志文件依次轉存到備份的數據庫中，進而為這一數據庫創(chuàng)建一個“近乎”熱備份。SQL Server 2000的數據庫引擎中設置了日志轉移功能，并在其中進行處理。所以它會自動完成復原到備份服務器的進程，而不需要數據庫管理員手動操作。只有你的產品服務器操作失敗，你才需手動完成到備份服務器的復原進程。(注釋：盡管SQL Server 7.0和2005中均有日志轉移功能，但本文主要針對SQL Server 2000。)
,B-y~5H/b91551
f(WQ]&UO@,S91551　　◆為什么要使用日志轉移?
2|http://space.itpub.net/35489/viewspace-420632

liyihongcug

Create Log ShippingITPUB個人空間/VuArL"e hF
1.       SQL Server 節(jié)點1 Tonym 和 Tonym02必須位于同一域中，并且SQL1 和SQL2都要使用域賬戶啟動SQL Server服務和SQLServerAgent服務。

2.       在企業(yè)管理器中刪掉local連接，應用Server Name注冊本地服務器 Tonym，輔助服務器Tonym02

3.       在SQL1 服務器上新建共享文件夾NorthwindBackupShare01，賦予啟動SQL Server賬戶的Full 權限。在SQL1服務器上新建文件夾 ReceiveSQL2Logs，用來在進行數據庫角色轉換時接收從SQL2上傳送過來的日志。

在SQL2 服務器上新建共享文件夾NorthwindBackupShare02，賦予啟動SQL Server賬戶　　　　的Full 權限。在SQL2服務器上新建文件夾 ReceiveSQL1Logs，用來接收數據庫SQL1上傳送過來的日志。

liyihongcug

安裝SQLSERVER2000時，會有這樣的一個選擇畫面，這是設置啟動sqlserver服務的登錄身份。SQLSERVER2000裝好后，會產生一個MSSQLSERVER服務，在這里設置的就是啟動它這個服務的登錄身份。

在選擇服務帳戶時，有本地帳戶和域用戶，默認是域用戶,兩者的區(qū)別如下：

本地帳戶是SQL安裝時所注冊用戶,本地系統(tǒng)帳戶可以沒有WINDOWS 2000的網絡訪問權限,但它可能限制SQL Server安裝與其他服務器交互, 域用戶帳戶使用 Windows 身份驗證，即用于連接到操作系統(tǒng)的用戶名和密碼也用于連接到 SQL Server。

選擇“域用戶”需要加入域中（存在域控制器），登錄驗證時使用域控制器中的用戶信息。而本地用戶使用本機用戶信息。

建議使用本地用戶，這樣即便域控制器失效也能正常啟動SQL Server

如果想使用用域用戶,而且它的權限更大,
應該首先把主機升級成域控制器，就可以用域用戶登錄了。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－
怎樣安裝域控制器:

選擇啟動菜單中的管理工具， 單擊"設置你的服務器"
選擇活動目錄， 單擊"開始" 啟動活動目錄安裝向導
根據活動目錄安裝向導的提示操作
如你想直接啟動活動目錄安裝向導， 可直接在 "運行"對話框中鍵入"dcpromo"


因為Windows Professional 不能成為域控制器 ，因而在Windows Professional
上沒有"設置你的服務器" 選項及"dcpromo"命令

在你使用 "活動目錄安裝向導"前， 先考慮一下幾點：

取得建立一個域的信息， 包括：用戶登錄名， 密碼，域名。 該用戶權賬號必須
具有足夠的權限來創(chuàng)建一個新的域控制器
你所需要的域控制器的類型：創(chuàng)建一個新域的域控制器還是為以有的域另增加一
個新的域控制器。 如你準備新生成一個域， 你必須決定是生成一個新的樹還是
加入一個已有的樹。
怎樣取消一個域控制器：

直接在"運行" 對話框中鍵入"depromo"
根據活動目錄安裝向導的提示操作
注意：

如果該域控制器含域的目錄，在取消改域控制器之前先確認一下是否有另外的域
控制器對用戶可見。
如果該域控制器正負責一些主操作， 將這些操作轉移到其他的域控制器上去。

如果該域含有子域， 它不能被刪除。 如果該域控制器是某一個域中最后一臺域
控制器， 刪除它意味著將整個域刪除。 同理對樹葉成立。

那么我們究竟要選擇哪一個呢？兩者各代表什么意思呢？下文我們就來研究一下。

我們先看熟悉一下兩個相關概念。

什么是憑據？
        Windows憑據（Credential）其實就是指用戶帳戶和口令，我們調用一些API，如 WTSOpenServer，QueryServiceStatus，NetUserEnum等等涉及到RPC的，只要當前用戶存儲有目標遠程機的權限合適的憑據，則這些API就不會因產生ERROR_ACCESS_DENIED而執(zhí)行失敗。
        不好理解么？那么我們來看一下訪問別的計算機的情形，加深理解。訪問遠程計算機必然用到rpc。

        上圖就是我們連接到IP為172.16.100.1計算時的情形，這個時候是需要我們輸入用戶帳戶與密碼的。這里的用戶帳戶與密碼就是所謂的憑據。

        當我們輸入用戶帳戶與密碼后，并把“記住我的密碼”打上勾，點確定。那么我們的憑據(即這個用戶帳戶與密碼)被存儲了，以后再訪問的時候就無須再輸入。

安全上下文
        安全上下文（Security context）是指在一個系統(tǒng)中有效的安全屬性或規(guī)則。

       下面我們來看SQLSERVER2000服務的兩種登錄方式：本地系統(tǒng)帳戶和域用戶帳戶

本地系統(tǒng)帳戶：

        該帳戶是對本地計算機具有管理員權限的預定義本地帳戶。在本地系統(tǒng)帳戶的安全上下文中運行的服務向遠程服務器提供本地計算機的憑據。在本地系統(tǒng)帳戶的安全上下文中運行的服務不能建立身份驗證會話，因為本地系統(tǒng)帳戶不屬于域中的 Everyone 組。因此，使用該帳戶的服務只能通過空會話(沒有憑據)來訪問網絡資源。(這個訪問指的是為了完成某項任務服務的自動訪問，和我們的連接SQL服務器不一概念)

域用戶帳戶：

使用專用域用戶帳戶作為登錄帳戶

        域用戶帳戶是指在 Active Directory 目錄服務中創(chuàng)建的用戶帳戶。該帳戶是域中 Authenticated Users 組的成員。在域用戶帳戶的安全上下文中運行的服務向遠程服務器提供域用戶帳戶的 Kerberos 票證。在域用戶帳戶的安全上下文中運行的服務可以訪問經過身份驗證的用戶或特定用戶帳戶有權訪問的遠程服務器上的資源。

使用本地用戶帳戶作為登錄帳戶

        本地用戶帳戶是指在本地計算機上創(chuàng)建的Windows用戶帳戶。在本地用戶帳戶的安全上下文中運行的服務向遠程服務器提供本地用戶帳戶的訪問標記。如果在遠程服務器上配置了匹配用戶名和密碼，則使用本地用戶帳戶的服務將能夠訪問同名帳戶有權訪問的遠程服務器上的資源。雖然此方案行之有效，但是維護這些單獨的帳戶并保持帳戶密碼同步將增加管理開銷。
        如果你沒有加入域，但又需要連接到網絡資源，那么可以使用本地用戶帳戶作為登錄帳戶。
        由此可見使用域用戶帳戶可以使用憑據來訪問遠程計算機，并使用相應的資源。

        例如SQLSERVER服務，當它進行以下操作時，是需要訪問遠程計算機的。
        • 遠程過程調用。
        • 復制。
         • 備份到網絡驅動器。
        • 涉及遠程數據源的異類聯接。
      • SQL Server 代理郵件功能和 SQL 郵件。

         在這幾種情況下是無法不使用憑證去訪問遠程計算機，并使用其資源的。所以必須得把登錄類型改為“域用戶帳戶”，并輸入在遠程計算機上配置好的，存在的“用戶名”和“密碼”。

如果只是裝在本機進行開發(fā)或學習，完全沒必要使用域用戶帳戶登錄模式，因為有時候因為切換不同用戶而導致服務不能啟動。

修改SQLSERVER服務的登錄類型

        服務的登錄類型是隨時可以改變的�？梢孕枰�的時候通過以下兩種方法修改SQLSERVER服務的登錄類型。

1． 通過企業(yè)管理器修改

   右擊SQLSERVER服務器---“屬性”---“安全性”下的“啟動服務帳戶”


2．通過服務修改

“控制面板”---“服務”----“MSSQLSERVER”，右擊---“屬性”---“登錄”

裝SQLSERVER時遇到的一些問題
1.在安裝時出現提示"command line option syntax error!type command /? for help"
    這是因為你可能把SQLSERVER的安裝文件放在了中文目錄下，可以你它改為英文目錄即可。每一級目錄都不能含有中文。
2.出現提示"以前的某個程序安裝已在安裝計算機上創(chuàng)建掛起的文件操作。運行安裝程序之前必須重啟計算機"
打開注冊表編輯器(或在命令行輸入:regedit)，在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Control\Session Manager中找到PendingFileRenameOperations項目，并刪除它。然后進行安裝。

http://hi.baidu.com/ethancheer/b ... 0f85dcac6e7521.html

liyihongcug

根據您提供的信息，我們建議您嘗試以下步驟進行排錯：



1. 使用域管理員帳號登錄到域控制器上，右鍵點擊“我的電腦”——“屬性”——“遠程”。

2. 點擊“選擇遠程用戶”——將需要登錄的域用戶添加進來。

3. 打開“默認域控制器安全策略”——“計算機配置”——“Windows設置”——“安全設置”——“本地策略”——“用戶權利分配”。

4. 確認“允許本地登陸”和“通過終端服務允許登錄”選項中都添加了需要登錄到域控制器的域用戶帳號。

5. 在命令提示符中輸入gpupdate /force，重啟計算機，刷新組策略。

6. 在客戶端上進行測試，查看問題是否依然存在。



我們不建議讓普通的域用戶帳號登錄到域控制器上，這是可能會對域控制器帶來一定的安全隱患。



希望我的回答對您有所幫助，如果有什么不清楚的地方，請您回帖。


Tom Zhang 張一平

liyihongcug

原創(chuàng)  windows2003域設置 收藏

目前很多公司的網絡中的PC數量均超過10臺:按照微軟的說法，一般網絡中的PC數目低于10臺，則建議采對等網的工作模式，而如果超過10臺，則建議采用域的管理模式，因為域可以提供一種集中式的管理，這相比于對等網的分散管理有非常多的好處，那么如何把一臺成員服務器提升為域控?

　　首先，當然是在成員服務器上安裝上Windows Server 2003，安裝成功后進入系統(tǒng)，
　　我們要做的第一件事就是給這臺成員服務器指定一個固定的IP，在這里指定情況如下:
　　機器名:Server
　　IP:192.168.5.1
　　子網掩碼:255.255.255.0
　　DNS:192.168.5.1(因為我要把這臺機器配置成DNS服務器)
　　由于Windows Server 2003在默認的安裝過程中DNS是不被安裝的，所以我們需要手動去添加，添加方法如下:“開始—設置—控制面板—添加刪除程序”，然后再點擊“添加/刪除Windows組件”，則可以看到如下畫面:

　　向下搬運右邊的滾動條，找到“網絡服務”，選中:

　　默認情況下所有的網絡服務都會被添加，可以點擊下面的“詳細信息”進行自定義安裝，由于在這里只需要DNS，所以把其它的全都去掉了，以后需要的時候再安裝:

　　然后就是點“確定”，一直點“下一步”就可以完成整個DNS的安裝。在整個安裝過程中請保證Windows Server 2003安裝光盤位于光驅中，否則會出現找不到文件的提示，那就需要手動定位了。
　　　　　　
　　安裝完DNS以后，就可以進行提升操作了，先點擊“開始—運行”，輸入“Dcpromo”，然后回車就可以看到“Active Directory安裝向導”
　　在這里直接點擊“下一步”:
　　　　
　這里是一個兼容性的要求，Windows 95及NT 4 SP3以前的版本無法登陸運行到Windows Server 2003的域控制器，我建議大家盡量采用Windows 2000及以上的操作系統(tǒng)來做為客戶端。然后點擊“下一步”:

　　在這里由于這是第一臺域控制器，所以選擇第一項:“新域的域控制器”，然后點“下一步”:

　　既然是第一臺域控，那么當然也是選擇“在新林中的域”:

　　在這里我們要指定一個域名，我在這里指定的是demo.com，

這里是指定NetBIOS名，注意千萬別和下面的客戶端沖突，也就是說整個網絡里不能再有一臺PC的計算機名叫“demo”，雖然這里可以修改，但個人建議還是采用默認的好，省得以后麻煩�！　　　�
　　在這里要指定AD數據庫和日志的存放位置，如果不是C盤的空間有問題的話，建議采用默認。

　　這里是指定SYSVOL文件夾的位置，還是那句話，沒有特殊情況，不建議修改:
　　　
第一次部署時總會出現上面那個DNS注冊診斷出錯的畫面，主要是因為雖然安裝了DNS，但由于并沒有配置它，網絡上還沒有可用的DNS服務器，所以才會出現響應超時的現像，所以在這里要選擇:“在這臺計算機上安裝并配置DNS，并將這臺DNS服務器設為這臺計算機的首選DNS服務器”。

　　“這是一個權限的選擇項，在這里，我選擇第二項:“只與Windows 2000或Window 2003操作系統(tǒng)兼容的權限”，因為在我做實驗的整個環(huán)境里，并沒有Windows 2000以前的操作系統(tǒng)存在”

　　這里是一個重點，還原密碼，希望大家設置好以后一定要記住這個密碼，千萬別忘記了，因為在后面的關于活動目錄恢復的文章上要用到這個密碼的。

　　這是確認畫面，請仔細檢查剛剛輸入的信息是否有誤，尤其是域名書寫是否正確，因為改域名可不是鬧著玩的，如果有的話可以點上一步進入重輸，如果確認無誤的話，那么點“下一步”就正式開安裝了:
　　　　　　
　　幾分鐘后，安裝完成:

　　點完成:
　　點“立即重新啟動”。

　　然后來看一下安裝了AD后和沒有安裝的時候有些什么區(qū)別，首先第一感覺就是關機和開機的速度明顯變慢了，再看一下登陸界面:
　　　　　　
　　多出了一個“登陸到”的選擇框:
　　進入系統(tǒng)后，右鍵點擊“我的電腦”選“屬性”，點“計算機”
　　　　　　
　　怎么樣?和安裝AD以前不一樣吧，其它的比如沒有本地用戶了，在管理工具里多出么多圖標什么的，這些將在以后的文章里講述，這里就不再詳談了。



把一臺成員服務器提升為域控制器(二)
在我的上一篇文章中，已經把一臺名為Server的成員服務器提升為了域控制器，那我們現在來看一下如何把下面的工作站加入到域。
由于從網絡安全性考慮，盡量少的使用域管理員帳號，所以先在域控制器上建立一個委派帳號，登陸到域控制器，運行“dsa.msc”，出現“AD用戶和計算機”管理控制臺:

　　先來新建一個用戶，展開“demo.com”，在“Users”上擊右鍵，點“新建”-“用戶”:

　　然后出現一個新建用戶的向導，在這里，我新建了一個名為“swg”的用戶，并且把密碼設為“永不過期”。


　　這樣點“下一步”，直到完成，就可以完成用戶的創(chuàng)建。然后在“demo.com”上點擊右鍵，先擇“委派控制”:

　　就會出現一個“委派控制向導”:

　　點擊“下一步”:

點擊中間的“添加”按鈕，并輸入剛剛創(chuàng)建的“swg”帳號:

　　然后點“確定”:

　　再點“下一步”:

　　在上面的畫面中，暫時不需要讓該用戶去“管理組策略鏈接”，所以在這里，僅僅選擇“將計算機加入到域”，然后點“下一步”:

　　最后是一個信息核對畫面，要是沒有什么問題的話，直接點“完成”就可以了。

接下來轉到客戶端，看看怎么把XP進來，在實驗中采用的客戶端操作系統(tǒng)是Windows XP專業(yè)版，需要大家注意的是Windows XP 的Home版由于針對的是家庭用戶，所以不能加入域，大家別弄錯了喲，我們先來設置一下這臺XP的網絡:
　　計算機名:TestXP
　　IP:192.168.5.5
　　子網掩碼:255.255.225.0
　　DNS服務器:192.168.5.1，

　　設置完網絡以后，在“我的電腦”上擊右鍵，選“屬性”，點“計算機名”。

　　在這里把“隸屬于”改成域，并輸入:“demo.com”，并點確定，這是會出現如下畫面:

　　輸入剛剛在域控上建的那個“swg”的帳號，點確定:

　　出現上述畫面就表示成功加入了，然后點確定，點重啟就算OK了。來看一下登陸畫面有沒有什么不一樣:

　　看到那個“登陸到”了吧，可以選擇域登陸還是本機登陸了，在這里選擇域“DEMO”，這樣就可以用域用戶進行登陸了。進入系統(tǒng)后，在“我的電腦”上擊右鍵，選“屬性”，點“計算機名”:

　看到用黑框標出來的地方和沒有加入到域的時候的區(qū)別的吧?
　　當把下面的客戶端加入到域后，如果域控制器處于關閉狀態(tài)或者死機的話，那么，會發(fā)現下面的客戶機無法登陸到域，所以再建立一臺域控制器，用來防止其中一臺出現意外損壞的情況是很有必要的。后來建立的那臺域控制器叫額外域控制器。來看看額外域控制器的建立過程吧:
　　當然網絡設置永遠是在第一步的:
　　計算機名:Bserver
　　IP:192.168.5.2
　　子網掩碼:255.255.255.0
　　DNS:192.168.5.1
　　既然是提升為域控制器，那么DNS組件也是要添加的，添加方法和我的第一篇文章中所定的一樣，這里就不再重復了。添加完成后，同樣是點擊“開始”-“運行”-“dcpromo”:
　　出現的向導和操作系統(tǒng)兼容性同安裝第一臺域控時是一樣的，唯一要注意的是下面的那個畫面:

　　安裝第一臺時選擇的是“新域的域控制器”，這里要選擇的是“現有域的額外域控制器”，然后點“下一步”:

　　在這里，輸入域的管理員帳號的密碼，在“域”里填入相應域的DNS全名或NetBios名，點“下一步”:

在這里一定要填入現有域的DNS全名，然后再點“下一步”，接下去的操作和安裝第一臺域控制器時是一樣的，所以就不再寫下去了，直到完成就可以了。

活動目錄之用戶配置文件
關于域用戶的開設在前面的文章中(如何把一臺成員服務器提升為域控制器(一)、(二))已經涉及過了，所以在這里開設用戶的方法就不再重復了，本篇文章主要向大家介紹一下用戶配置文件。
　　首先，什么是用戶配置文件?根據微軟的官方解釋:用戶配置文件就是在用戶登陸時定義系統(tǒng)加載所需環(huán)境的設置和文件和集合，它包括所有用戶專用的配置設置。用戶配置文件存在于系統(tǒng)的什么位置呢?那么用戶配置文件包括哪些內容呢?來給大家看一副截圖:

　　用戶配置文件的保存位置在:系統(tǒng)盤(一般是C盤)下的“Documents and Settings”文件夾下，有一個和你的登陸用戶名相同的文件夾，該用戶配置文件就保存在這里，順便提示一下，如果本機和域上有一個同名用戶，并且都登陸過的話，那么就會出現在同名文件夾后面拖后綴的情況，舉個例子:比如在一個域(demo.com)里面有一臺計算機(testxp)，本地有一個swg 的帳號，域上也有一個swg的帳號，并且都登陸過這臺計算機，那么會發(fā)生如下情況:
　　本地帳號先登陸:那么本地的swg的用戶配置文件夾為swg，而域用戶的用戶配置文件夾為swg.demo。
　　域帳號先登陸:那么域用戶的用戶配置文件夾為swg，本地用戶的配置文件夾為swg.testxp。
　　通過上面的截圖，我們可看出，用戶配置文件包括桌面設置、我的文檔、收藏夾、IE設置等一些個性化的配置。另外需要說明的是在“Documents and Settings”文件夾下有一個名為“All Users”的文件夾，如果你在這個文件夾下的“桌面”文件夾下新建一個文件的話，你會發(fā)現所有用戶在登陸時的桌面上都有這個文件，所以這個文件夾里的配置是對這臺計算機的每個用戶均起作用的。
當網絡變成域構架后，所有的域用戶可以在任意一臺域內的計算機登陸，當你在一臺計算機上的用戶配置文件修改后，你會發(fā)現到另一臺計算機上登陸時，所有的設置還是原來的，并沒有發(fā)生修改，這是因為用戶的配置文件是保存在本地的，不管是域用戶還是本地用戶，都是保存在那臺登陸的計算機上。我們可以在“我的電腦”上擊“右鍵”，選“屬性”，點“高級”，然后在“用戶配置文件”里點“設置 ”:

　　請注意“類型”里用紅框標出的部分，全部是“本地”，這就說明用戶配置文件保存在本地，那么如何才能讓用戶的配置文件隨著帳號走，也就是不管用戶在哪臺計算機上登陸都能保持用戶配置文件一致呢?為了解決這個問題，就要用到漫游用戶配置文件，原理就是把用戶配置文件保存在一個網絡的公共位置，當用戶在計算機上登陸里，會從網絡公共位置把用戶配置文件下載到本地并加以應用，然后當用戶注銷時，會把本地的用戶配置文件同步到網絡公共位置，以保證公共位置用戶配置文件的有效性，以便下一次使用。那么如何來實現這個功能呢?現在就來實踐一下:
　　首先，要在一個網絡的公共位置開設一個共享文件夾，用來存放用戶配置文件，在個實驗里，就在域控制器上開設一個為share的共享文件夾，并開放權限:

　　然后，點擊“開始-設置-控制面板-管理工具”，雙擊“AD用戶和計算機”，并選中相應的用戶，這里以“swg”帳號為例:

在“swg”帳號上雙擊，然后選“配置文件”，在“用戶配置文件-配置文件路徑”里輸入:\\192.168.5.1\share\%username%，“192.168.5.1”是域控制器的IP地址，如下圖所示:

　　然后點確定，接下去就到客戶端去，用“swg”帳號登陸一下，看看會發(fā)生什么變化。

　　如上圖所示，DEMO\swg的狀態(tài)由剛剛的“本地”變成了“漫游”，此時注銷一下用戶，那么就會自動的將該用戶的本地用戶配置文件同步到網絡公共位置，如果再用“swg”到另外的域內計算機上去登陸的話，會發(fā)現所有的用戶配置文件和這臺計算機上是一樣的。那么服務器上發(fā)生了些什么變化呢?

　　如上圖所示，服務器的“share”文件夾里會自動創(chuàng)建一個和用戶名一樣的“swg”文件夾，默認情況下這個文件夾只允許對應的用戶打開:

　　畫面很熟悉吧?
目前很多公司的IT Pro都有共同的感嘆，就是用戶喜歡把自己的桌面什么的搞得亂七八糟，雖然通過組策略可以限制掉一部份，但總覺得不是很完善，在這里，向大家推薦使用強制用戶配置文件，用戶可以對自己個人配置文件任意修改，但是一旦注銷后，這些修改將不會被保存，這樣用戶下次登陸里，用戶的配置文件還是保持和原來一樣，那么如何實現這個功能呢?其實只要將用戶配置文件夾下的“Ntuser.dat”改成“Ntuser.man”就可以了，來看一下修改過程:
　　首先，在顯示隱藏文件和已知文件的擴展名，可以在“工具-文件夾選項-查看”里進行修改：
~
　　點“確定”后，就可以在看到那個“Ntuser.dat”文件了，但此時會有一個問題，如果去修改C:\Documents and Settings\swg下的“Ntuser.dat”，會發(fā)現根本沒有辦法修改這個文件，因為文件在使用中，無法修改;如果去修改網絡公共位置的 “Ntuser.dat”，也就是\\192.168.5.1\share\swg下的“Ntuser.dat”，修改當然可以修改，但是由于在 “swg”用戶注銷的時候，本地的“Ntuser.dat”會把網絡公共位置的“Ntuser.man”覆蓋掉，也就是等于沒有修改。很多人都想直接在服務器上更改 “swg”文件夾的所有者，然后給管理員帳號添加權限，這樣就可以直接在服務器上把“Ntuser.dat”改掉，但本人實踐過幾次，都發(fā)現這樣的操作會引起一些權限無法繼承，而導致出錯的情況，所以不建議大家使用，這里推薦一種方法:
　　先把“swg”帳號注銷掉，然后用另外一個帳號登陸，比如管理員，當然，如果在登陸成功后直接去訪問\\192.168..5.1\share\swg以試圖修改的話，那么你將會感到失望，因為還是拒絕訪問的，那么如何訪問并修改呢，可以這樣操作，“開始-運行-cmd”然后回車，這樣就啟動了命令行，在命令行下輸入:net use \\192.168.5.1 password /user:swg，顯示“命令成功完成”，這樣就利用“swg”和服務器建立一個連接，此時就可以\\192.168.5.1\share\swg，里進行修改了，

　　然后再注銷管理員帳號，用“swg”登陸，看看有沒有成功:

　　看到了吧，類型由“漫游”變成了“強制”，現在可以在桌面這些地方進行任意的修改，你會發(fā)現注銷再登陸，又恢復到了原樣。這種設置在多人使用同一個帳號的情況下非常有用。
　　最后再請大家注意兩個問題:
　　1、 在配置強制用戶配置文件時，當用其它用戶登陸修改時，請保證被修改的用戶處于注銷狀態(tài)，為什么?大家不妨自己想一想!
　　2、 當使用漫游用戶配置文件時，請不要在桌面等地方存放一些大型的程序或文件，因為用戶在登陸和注銷過程中會下載和上傳配置文件，如果文件過大，會影響登陸和注銷的速度。

liyihongcug

如何使用向導設置SQL Server 2005日志傳送（三）
時間:2010-09-07 16:41來源:互聯網 作者:互聯網 點擊:499次
SQL Server 2005,作者在本文中繼續(xù)介紹如何使用向導設置SQL Server 2005日志傳送。文中的這個向導有許多的選擇并且對于新手而言可能有些困惑。但是，在大多數情況下默認值都是……
此文來自人人IT網，請訪問www.renren.it獲取更多內容
【TechTarget中國原創(chuàng)】在此對話框中，你可以選擇副服務器（你將把事務日志拷貝到這個服務器上）以及副數據庫（日志所要傳送到的數據庫名稱）。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　注意下面這些針對Initialize Secondary Database的選項：
此文來自人人IT網，請訪問www.renren.it獲取更多內容

    * Yes， generate a full backup of the primary and restore it into the secondary database.這個選項創(chuàng)建了一個你想要進行日志傳送的數據庫的備份，然后將它恢復到副服務器上。
    * Yes， restore an existing backup of the primary database.如果你想要使用一個之前備份的數據庫，就可以使用這個選項。這里有一個選項用于選擇路徑和備份名稱。
    * No， the secondary database is initialized.Use this option if:在以下情況使用這個選項：　

　　　　1、你想要進行日志傳送的數據庫備份已經恢復到副數據庫了。　
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　　　2、主數據庫已經是完整或批量日志恢復模式�！�
　
　　　　3、從備份發(fā)生后主數據庫上沒有再做任何事務日志備份，或者它們已經完成，并恢復到副數據庫上了。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　　　4、副數據庫已經使用無恢復選項重建好了。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　一旦你已經配置了最適合你的選項，點擊“Copy Files”標簽，如圖8所示。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　Copy Files對話框
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　圖8：Copy Files對話框。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　在“Copy Files”標簽中選擇你從主服務器到副服務器上拷貝文件的存放位置。如果你在Transaction Log Backup Settings（如圖1所示）中選擇一個網絡路徑，那么網絡途徑必須映射到副服務器的物理位置上，同時你必須在此處輸入路徑（如，如果\\ServerName\ShareName$是本地路徑C:\Backup的共用名，那么就在此處輸入這個路徑）。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　你也可以使用事務日志備份存儲在主服務器上的網絡路徑。選擇你想要保留事務日志備份的時間長度——當然，必須認識到，保留時間可能與你在“Transaction Log Backup Settings”對話框（圖1）中的設置沖突。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　你同樣還可以選擇你希望日志拷貝到副服務器上的頻率。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　一旦你配置好了拷貝的事務日志備份文件的選項，點擊“Restore Transaction Log ”標簽，如圖9所示。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　Restore Transaction Log標簽
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　圖9：Restore Transaction Log標簽
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　數據庫恢復狀態(tài)選項：
此文來自人人IT網，請訪問www.renren.it獲取更多內容

    * 無恢復模式——這是一個默認選項。在這個選項中，目的地數據庫將無法使用。
    * 備用模式——使用這個選項，在下一個事務日志備份應用之前，目的地數據庫僅僅是只讀形式。在事務日志被應用后，數據庫重新將返回只讀模式。這樣就只允許只讀訪問并且用戶將無法對數據庫作任何修改（如，創(chuàng)建索引），而且在下一個數據庫備份被應用時，他們將被斷開。

　　還有一個選項是通過設置一組小時或分鐘數來延遲恢復事務日志備份。有些企業(yè)想要保持他們的備用服務器與他們的源服務器幾個小時不同步。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　在默認情況下，如果事務日志在定義的“Alert if no restore occurs within”間隔的時間內沒有恢復，那么就會有一個告警信息發(fā)出。通常情況下，這個警告是發(fā)生在主服務器進行備份操作的時候。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　你還有一個選項就是設置事務日志恢復發(fā)生的頻率。這些設置是在Restore任務對話窗口配置的。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　你設置好后，點擊“OK”，然后你將看到“Database Properties”對話框（如圖10所示）的“Transaction Log Shipping”對話框。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　Transaction Log Shipping標簽
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　圖10：Transaction Log Shipping標簽
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　在此對話框中，注意我們是如何配置服務器F作為我們的副服務器，同時該數據庫p2p3是我們日志傳送Northwind數據庫的目地數據庫。你也可以日志傳送到第二個副/備用服務器——這個可能是你的DR站點的另外一個副服務器。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　對于任何具備大量日志傳輸數據庫的企業(yè)，你可能都想要創(chuàng)建一個監(jiān)控服務器。選擇“Use a monitor server instance”（圖10）然后點擊設置按鈕來配置一個Log Shipping Monitor服務器，就可以創(chuàng)建一個檢測服務器。如圖11所示。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　創(chuàng)建一個監(jiān)控服務器
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　圖11：創(chuàng)建一個監(jiān)控服務器。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　使用連接按鈕，你可以連接到你想用作監(jiān)控的服務器。定義連接方式，或者通過Windows認證，或者通過SQL Server登錄。你可以定義工作歷史保留時間，但通常使用默認值都是一個不錯的選擇，然后定義如何發(fā)送警報。默認選項（當SQL Server Agent啟動時自動啟動）是一個不錯的選擇，因為這時警報幾乎都是實時的。你可以選擇一個每小時提醒或者選擇一個任意時間間隔。
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　總結
此文來自人人IT網，請訪問www.renren.it獲取更多內容

　　這樣我們就完成了使用SQL Server 2005的日志傳送的介紹。這個向導有許多的選擇并且對于新手而言可能有些困惑。但是，在大多數情況下默認值都是最優(yōu)選項，并且我已經指出了在什么情況下最好選擇非默認選項。
此文來自人人IT網，請訪問www.renren.it獲取更多內容
Hilary Cotter

Hilary Cotter， SQL Server MVP 是一名有著20多年IT從業(yè)經驗的Web和數據庫顧問，并且與SQL Server打了11年的交道。Cotter是RelevantNoise的Text Mining總監(jiān)，致力于商業(yè)智能的博客索引。在2001年，他首次被Microsoft授予Microsoft SQL Server MVP。Cotter在University of Toronto獲得了機械工程的應用科學學士學位，同時還在University of Calgary學習經濟學和UC Berkeley學習計算機科學。他撰寫了《A Guide to SQL Server 2000 Transactional and Snapshot Replication》，并且目前致力于合并復制和Microsoft搜索技術。你可以通過hilary.cotter@gmail.com與Hilary Cotter取得聯系。
此文來自人人IT網，請訪問www.renren.it獲取更多內容
如何使用向導設置SQL Server 2005日志傳送（三）

本文摘自：http://www.searchdatabase.com.cn/showcontent_17302.htm

http://www.renren.it/a/shujuku/Sqlserver/20100907/18190.html