当前位置：首页 > 实用文档 > 其他范文> Sybase master库日志管理数据库

Sybase master库日志管理数据库

时间：2023-09-21 08:21:33 其他范文收藏本文下载本文

Sybase master库日志管理数据库（精选8篇）由网友“霸道总裁蕾哈娜”投稿提供，下面给大家分享Sybase master库日志管理数据库，欢迎阅读!

篇1：Sybase master库日志管理数据库

Sybase master 库日志满了应该如何清除呢?可以通过以下的方法对 master库进行管理，如果确实没有足够的空间了，可以考虑对 master库进行扩容操作， 1、简单的情况下 dump trans with no_log 就可以了，master库一般不会满。 1 use master 2 go 1 checkpoint

Sybase master 库日志满了应该如何清除呢?可以通过以下的方法对 master库进行管理，如果确实没有足够的空间了，可以考虑对 master库进行扩容操作。

1、简单的情况下 dump trans with no_log 就可以了，master库一般不会满。

1>use master

2>go

1>checkpoint

2>go

1>dump tran master with no_log

2>go

00:00000:00011:/02/22 14:53:38.06 server WARNING: *************************

00:00000:00011:2006/02/22 14:53:38.06 server Attempt by user 1 to dump xact on

db master with NO_LOG

00:00000:00011:2006/02/22 14:53:38.06 server Attempt by user 1 to dump xact on

db master with NO_LOG was suclearcase/“ target=”_blank“ >ccessful

00:00000:00011:2006/02/22 14:53:38.06 server WARNING: *************************

2、如果是windows平台，则找到RUN_your_server_name.bat

如果是Unix平台，则找到RUN_your_server_name文件

编辑上面的启动文件，在行尾加上 -T3067

然后使用启动文件启动数据库，启动后

dump tran master with truncate_onlyu

1）备份master数据库

dump database master to '备份路径及文件名'

2）停止sybase服务

shutdown

3）编辑sybase服务启动文件(在unix下一般是“RUN_服务名”的文件，在windows下一般是“RUN_服务名.bat”的批处理文件)，

在启动文件的命令行最后加上 -T3607)

4）使用启动文件启动服务后，再dump tran master with truncate_only

5）这时dump清理日志一般多会成功。然后在停止shutdown服务，去掉-T3607，以正常方式启动服务

3、不行的话，则需要建立一设备来进行扩展或按以下方式重建:

1）备份master数据库

启动backup server，进入isql环境执行:

1>dump database master to '/sybase/master.dump'

2>go

(如果不行的话 dump 日志 with no log)

hut downSQL/ASE Server

1>shutdown

2>go

2）创建新的足够大的master设备

$buildmaster -d-ssize(size以2K为单位)

例:$buildmaster-d/sybase/data/master.dat -s102400

3）修改RUN_servername文件

编辑RUN_server_name文件，-d参数指向新建的设备名。

4）单用户模式重启server

$startserver -f RUN_servername -m

5）执行installmaster脚本

6）由备份文件装载master数据库

1>load database master from '/sybase/master.dump'

2>go

7）修改sysdevices信息

sp_configure 'allow updates', 1

begin tran

update sysdevices set high = 102399 , phyname = 'e:\sybase\data\master_test.dat' where name = 'master'

(102399=200*512-1 master设备大小为200M)

commit tran

8）扩展master数据库

1>alter database master on master设备名称=size(此值以M为单位)

2>go

例:alter database master on master=10

将master数据库在master设备上扩展10M

这个操作比较危险，注意先做好备份(比如 GHOST)

(责任编辑：铭铭)

原文转自：www.ltesting.net

篇2：Sybase的master库日志管理

Sybase master 库日志满了应该如何清除呢?

可以通过以下的方法对 master库进行管理，如果确实没有足够的空间了，可以考虑对 master库进行扩容操作，

1、简单的情况下 dump trans with no_log 就可以了，master库一般不会满。

1>use master

2>go

1>checkpoint

2>go

1>dump tran master with no_log

2>go

00:00000:00011:2006/02/22 14:53:38.06 server WARNING: *************************

00:00000:00011:2006/02/22 14:53:38.06 server Attempt by user 1 to dump xact on

db master with NO_LOG

00:00000:00011:2006/02/22 14:53:38.06 server Attempt by user 1 to dump xact on

db master with NO_LOG was successful

00:00000:00011:2006/02/22 14:53:38.06 server WARNING: *************************

2、如果是windows平台，则找到RUN_your_server_name.bat

如果是Unix平台，则找到RUN_your_server_name文件

编辑上面的启动文件，在行尾加上 -T3067

然后使用启动文件启动数据库，启动后

dump tran master with truncate_onlyu

1）备份master数据库

dump database master to '备份路径及文件名'

2）停止sybase服务

shutdown

3）编辑sybase服务启动文件(在unix下一般是“RUN_服务名”的文件，在windows下一般是“RUN_服务名.bat”的批处理文件)，

在启动文件的命令行最后加上 -T3607)

4）使用启动文件启动服务后，再dump tran master with truncate_only

5）这时dump清理日志一般多会成功。然后在停止shutdown服务，去掉-T3607，以正常方式启动服务

3、不行的话，则需要建立一设备来进行扩展或按以下方式重建:

1）备份master数据库

启动backup server，进入isql环境执行:

1>dump database master to '/sybase/master.dump'

2>go

(如果不行的话 dump 日志 with no log)

hut down SQL/ASE Server

1>shutdown

2>go

2）创建新的足够大的master设备

$buildmaster -d -ssize(size以2K为单位)

例:$buildmaster-d/sybase/database/master.dat -s102400

3）修改RUN_servername文件

编辑RUN_server_name文件，-d参数指向新建的设备名。

4）单用户模式重启server

$startserver -f RUN_servername -m

5）执行installmaster脚本

6）由备份文件装载master数据库

1>load database master from '/sybase/master.dump'

2>go

7）修改sysdevices信息

sp_configure 'allow updates', 1

begin tran

update sysdevices set high = 102399 , phyname = 'e:\sybase\data\master_test.dat' where name = 'master'

(102399=200*512-1 master设备大小为200M)

commit tran

8）扩展master数据库

1>alter database master on master设备名称=size(此值以M为单位)

2>go

例:alter database master on master=10

将master数据库在master设备上扩展10M

这个操作比较危险，注意先做好备份(比如 GHOST)

篇3：Scala 数据库访问库：Scala Slick

Slick 是 TypeSafe 推出的 Scala 数据库访问库，开发者可以使用 Scala 语言风格来编写数据查询，而不是用 SQL，

示例代码：

object Coffees extends Table[(String, Int, Double)](”COFFEES“) { def name = column[String](”COF_NAME“, O.PrimaryKey) def supID = column[Int](”SUP_ID“) def price = column[Double](”PRICE“) def * = name ~ supID ~ price}Coffees.insertAll( (”Colombian“, 101, 7.99), (”Colombian_Decaf“, 101, 8.99), (”French_Roast_Decaf“, 49, 9.99)) val q = for { c <- Coffees if c.supID === 101 // ^ comparing Rep[Int] to Rep[Int]!} yield (c.name, c.price)println(q.selectStatement)q.foreach { case (n, p) =>println(n + ”: “ + p) }

项目主页：www.open-open.com/lib/view/home/136076354

篇4：SYBASE数据库日志详解

SYBASE公司是世界著名的数据库厂家，其关系数据库产品SYBASE SQL Server在中国大中型企事业单位中拥有大量的用户，笔者在多年的使用过程中，总结出SYBASE数据库管理和维护的一些经验，现拿出来与大家分享。我们知道，SYBASE SQL Server用事务（Transaction）来跟踪所有数据库的变化。事务是SQL Server的工作单元。一个事务包含一条或多条作为整体执行的T-SQL语句。每个数据库都有自己的事务日志（Transaction Log），即系统表（Syslogs）。事务日志自动记录每个用户发出的每个事务。日志对于数据库的数据安全性、完整性至关重要，我们进行数据库开发和维护必须熟知日志的相关知识。

一、SYBASE SQL Server如何记录和读取日志信息

SYBASE SQL Server是先记Log的机制。每当用户执行将修改数据库的语句时，SQL Server就会自动地把变化写入日志。一条语句所产生的所有变化都被记录到日志后，它们就被写到数据页在缓冲区的拷贝里。该数据页保存在缓冲区中，直到别的数据页需要该内存时，该数据页才被写到磁盘上。若事务中的某条语句没能完成，SQL Server将回滚事务产生的所有变化。这样就保证了整个数据库系统的一致性和完整性。

二、日志设备

Log和数据库的Data一样，需要存放在数据库设备上，可以将Log和Data存放在同一设备上，也可以分开存放。一般来说，应该将一个数据库的Data和Log存放在不同的数据库设备上。这样做有如下好处：一是可以单独地备份Backup事务日志；二是防止数据库溢满；三是可以看到Log的空间使用情况。

所建Log设备的大小，没有十分精确的方法来确定。一般来说，对于新建的数据库，Log的大小应为数据库大小的30%左右。Log的大小还取决于数据库修改的频繁程度。如果数据库修改频繁，则Log的增长十分迅速。所以说Log空间大小依赖于用户是如何使用数据库的。此外，还有其它因素影响Log大小，我们应该根据实际操作情况估计Log大小，并间隔一段时间就对Log进行备份和清除。

三、日志的清除

随着数据库的使用，数据库的Log是不断增长的，必须在它占满空间之前将它们清除掉。清除Log有两种方法：

1.自动清除法

开放数据库选项 Trunc Log on Chkpt，使数据库系统每隔一段时间自动清除Log。此方法的优点是无须人工干预，由SQL Server自动执行，并且一般不会出现Log溢满的情况；缺点是只清除Log而不做备份，

2.手动清除法

执行命令“dump transaction”来清除Log。以下两条命令都可以清除日志：

dump transaction with truncate_only

dump transaction with no_log

通常删除事务日志中不活跃的部分可使用“dump transaction with trancate_only”命令，这条命令写进事务日志时，还要做必要的并发性检查。SYBASE提供“dump transaction with no_log”来处理某些非常紧迫的情况，使用这条命令有很大的危险性，SQL Server会弹出一条警告信息。为了尽量确保数据库的一致性，你应将它作为“最后一招”。

以上两种方法只是清除日志，而不做日志备份，若想备份日志，应执行“dump transaction database_name to dumpdevice”命令。

四、管理庞大的事务

有些操作会大批量地修改数据，如大量数据的修改（Update）、删除一个表的所有数据（Delete）、大量数据的插入（Insert），这样会使Log增长速度很快，有溢满的危险。下面笔者给大家介绍一下如何拆分大事务，以避免日志的溢满。

例如执行“update tab_a set col_a=0”命令时，若表tab_a很大，则此Update动作在未完成之前就可能使Log溢满，引起1105错误（Log Full），而且执行这种大的事务所产生的独占锁（Exclusive Table Lock），会阻止其他用户在执行Update操作期间修改这个表，这就有可能引起死锁。为避免这些情况发生，我们可以把这个大的事务分成几个小的事务，并执行“dump transaction”动作。

上例中的情况就可以分成两个或多个小的事务：

update tab_a set col_a=0 where col_b>x

dump transaction database_name with truncate_only

update tab_a set col_a=0 where col_b <=x

dump transaction database_name with truncate_only

这样，一个大的事务就被分成两个较小的事务。

按照上述方法可以根据需要任意拆分大的事务。若这个事务需要备份到介质上，则不用“with truncate_only”选项。若执行“dump transaction with truncate_only”命令，应该先执行“dump database”。以此类推，我们可以对表删除、表插入等大事务做相应的拆分。

篇5：Informix 日志分析数据库

大家都知道informix是需要日志的，但各日志都做什么用，各有什么意义等等，我们在下面做一个探讨：首先需要说明的是informix的日志有两种：一种是物理日志，用来存放数据的前映象；另一种是逻辑日志，用来存放所有事物的操作过程，在初始化的配置中，物理

大家都知道informix是需要日志的，但各日志都做什么用，各有什么意义等等，我们在下面做一个探讨：

首先需要说明的是informix的日志有两种：一种是物理日志，用来存放数据的前映象；另一种是逻辑日志，用来存放所有事物的操作过程。

在初始化的配置中，物理日志和逻辑日志的不是存放在根的磁盘空间的。默认的大小物理日志2M，逻辑日志6个，每个日志文件2M。但在实际的生产环境中，这两个参数一般是需要调整的。

从informix的本身的建议来说，要求逻辑日志的大小一般是要求一天的业务量，逻辑日志滚一圈，物理日志/逻辑日志=1/3。但是有的数据量很大的业务系统，这样做是不可能的，要做适当的调整。

物理日志文件的个数仅为1，逻辑日志文件的个数最小为3，最大为32767。关于物理日志和逻辑日志的改变，我们可以使用onparams命令来完成。

C:\Informix>onparams --

Usage: onparams -a -d [-s ] [-i] |

-d -l [-y] |

-p -s [-d ] [-y]

-a - Add a logical log file

-i - Insert after current log

-d - Drop a logical log file

-p - Change physical log size and location

-y - Automatically responds ”yes“ to all prompts

上面是onparams的帮助文件，下面我们首先来改变物理日志的位置和大小：

C:\Informix>onparams -p -s 40000 -d phydbs -y

Shutting down, please wait ...

Initializing, please wait ...

Recovering, please wait ...

可以通过onstat Cl 中的phybegin来查看物理日志当前存在了哪个chunk上。Physize来查看当前物理日志文件大大小，单位是页。在这之前我们创建了phydbs，并指定了他大小。我们在-s后指定物理日志文件的大小，在-d后指定物理日志文件的位置。接着我们来做逻辑日志位置和大小的改变：

C:\Informix>onparams -a -d logdbs -s 30000 -i

Logical log suclearcase/” target=“_blank” >ccessfully added.

然后用onstat Cl来查看新加的逻辑日志：

C:\Informix>onstat -l

IBM Informix Dynamic Server Version 9.40.TC2E1 -- Quiescent -- Up 00:08:10 -- 25728 Kbytes

Physical Logging

Buffer bufused bufsize numpages numwrits pages/io

P-1 0 8 8 7 1.14

phybegin physize phypos phyused %used

3:53 10000 12 0 0.00

Logical Logging

Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io

L-3 0 8 37 14 14 2.6 1.0

Subsystem numrecs Log Space used

OLDRSAM 37 2628

address number flags uniqid begin size used %used

0CB37CA8 1 U-B---- 1 1:763 500 500 100.00

0CB37CE8 2 U-B---- 2 1:1263 500 500 100.00

0CB37D28 3 U-B---- 3 1:1763 500 500 100.00

0CB37D68 4 U-B---- 4 1:2263 500 500 100.00

0CB37DA8 5 U-B---- 5 1:2763 500 284 56.80

0CB37DE8 6 U---C-L 6 1:3263 500 315 63.00

0CED8B98 12 A------ 0 2:37553 7500 0 0.00

0CED8B58 11 A------ 0 2:30053 7500 0 0.00

0CED8B18 10 A------ 0 2:22553 7500 0 0.00

0CED8AD8 9 A------ 0 2:15053 7500 0 0.00

0CED8A98 8 A------ 0 2:7553 7500 0 0.00

0CED8A58 7 A------ 0 2:53 7500 0 0.00

12 active, 12 total

可以发现新加的逻辑日志状态都是A,先做0级备份ontape Cs CL 0之后用onstat Cl可以发现所有日志的flag位都变成了F状态，

然后用onmode Cl切换逻辑日志到新加的逻辑日志，用onmode Cc强制做检查点操作。最后用onparams Cd Cl log_file_num Cy来删除原来的逻辑日志文件。这样就完成了informix日志的迁移。

在onstat Cl中，flag位表示了逻辑日志的状态，

A表示新加了还不能使用的日志

F表示空闲的可以使用的日志，一般是在0级备份之后才有这样的状态

U表示已经使用的逻辑日志

L表示当前的日志文件包含一个检查点

C表示正在使用当前的日志文件

B表示已经备份的日志文件

一般在新增或删除日志文件之后都要做0级备份。

在onconfig文件中，LOGFILES指定了IDS逻辑日志的个数，LOGSIZE指定了逻辑日志的大小，PHYSDBS指定了物理日志的位置，PHYSFILE指定了物理日志大小。LTAPEDEV指定了逻辑日志备份的位置，LTAPEBLK指定了每个block块的大小，LTAPESIZE指定了备份文件的大小。

下面我们讨论数据库的日志模式：

无日志

无缓冲日志

缓冲日志

ansi模式

我们可以通过ontape 来改变日志的模式

采用无日志的方式时，所有的DML语句都不写日志，也就是说此时，数据库不支持事物。当数据库恢复系统备份的时候，无日志的数据库不能完全恢复。因为在备份中只记录了备份时的状态，备份后的数据库的变化必须从逻辑日志中恢复，所以这些改变是不可恢复的。

缓冲日志：所有的DML语句都写入log buffer,当log buffer写满的时候，就开始写入磁盘。这样就可以大大减少磁盘的I/O，从而提高数据库的性能。但是在系统发生问题恢复的时候，缓冲区内的数据将丢失。这些数据是不可能恢复的。

无缓冲日志模式：所有的 DML语句在发生的时候是写到缓冲里的，但事物commit之后就立刻写回磁盘，这样在系统发生问题就保证了数据丢失的最少，但是增加了磁盘的I/O，所以数据库的性能会受到一定的影响。

Ansi模式：此模式和无缓冲日志模式具有相同的日志缓冲处理方法，但是此模式是不可逆的。

另外BLOB日志的处理也是十分特别的，他不需要物理日志，不写前映象。BLOB页是直接写磁盘的，不经过共享内存的处理。任何BLOB空闲映象的改变都将记录到逻辑日志中，所有的blob spaces数据刷新到硬盘上是随逻辑日志的的备份而写下去的。

原文转自：www.ltesting.net

篇6：有关日志压缩数据库教程

压缩

SET QUOTED_IDENTIFIER OFF

SET ANSI_NULLS OFF

CREATE PROCEDURE strink_logspace

SET NOCOUNT ON

DECLARE @LogicalFileName sysname,

@MaxMinutes INT,

@NewSize INT

SELECT @LogicalFileName = rtrim(name),

@MaxMinutes = 10, -- 最大执行时间

@NewSize = 10 -- 最小空间

from sysfiles where status & 0x40 = 0x40

-- Setup / initialize

DECLARE @OriginalSize int

SELECT @OriginalSize = size -- in 8K pages

FROM sysfiles

WHERE name = @LogicalFileName

SELECT db_name +'日志原始大小' +

CONVERT(VARCHAR(30),@OriginalSize) + ' pages/ 8K 或 ' +

CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'

FROM sysfiles

WHERE name = @LogicalFileName

CREATE TABLE DummyTrans

(DummyColumn char (8000) not null)

-- Wrap log and truncate it.

DECLARE @Counter INT,

@StartTime DATETIME,

@TruncLog VARCHAR(255)

SELECT @StartTime = GETDATE(),

@TruncLog = 'BACKUP LOG ['+ db_name() + '] WITH TRUNCATE_ONLY'

-- Try an initial shrink.

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) -- the log has not shrunk

AND (@OriginalSize * 8 /1024) >@NewSize -- The value passed in for new size is smaller than the current size.

BEGIN -- Outer loop.

SELECT @Counter = 0

WHILE ((@Counter < @OriginalSize / 16) AND (@Counter < 50000))

BEGIN -- update

INSERT DummyTrans VALUES ('Fill Log') -- Because it is a char field it inserts 8000 bytes.

DELETE DummyTrans

SELECT @Counter = @Counter + 1

END -- update

EXEC (@TruncLog) -- See if a trunc of the log shrinks it.

END -- outer loop

DBCC SHRINKFILE (@LogicalFileName, @NewSize)

SELECT db_name() +'日志最后大小' +

CONVERT(VARCHAR(30),size) + ' pages/ 8K 或 ' +

CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'

FROM sysfiles

WHERE name = @LogicalFileName

DROP TABLE DummyTrans

PRINT '*** 数据库日志压缩成功 ***'

SET NOCOUNT OFF

SET QUOTED_IDENTIFIER OFF

SET ANSI_NULLS ON

--used

exec strink_logspace

篇7：SYBASE数据库日志详解数据库

我们知道，SYBASE SQL Server用事务（Transaction）来跟踪所有数据库的变化，事务是SQL Server的工作单元。一个事务包含一条或多条作为整体执行的T-SQL语句。每个数据库都有自己的事务日志（Transaction Log），即系统表（Syslogs）。事务日志自动记录每个用

我们知道，SYBASESQLServer用事务（Transaction）来跟踪所有数据库的变化。事务是SQL Server的工作单元。一个事务包含一条或多条作为整体执行的T-SQL语句。每个数据库都有自己的事务日志（Transaction Log），即系统表（Syslogs）。事务日志自动记录每个用户发出的每个事务。日志对于数据库的数据安全性、完整性至关重要，我们进行数据库开发和维护必须熟知日志的相关知识。

一、SYBASESQL Server如何记录和读取日志信息

二、日志设备

Log和数据库的Data一样，需要存放在数据库设备上，可以将Log和Data存放在同一设备上，也可以分开存放。一般来说，应该将一个数据库的Data和Log存放在不同的数据库设备上。这样做有如下好处：一是可以单独地备份?Backup?事务日志；二是防止数据库溢满；三是可以看到Log的空间使用情况。

三、日志的清除

随着数据库的使用，数据库的Log是不断增长的，必须在它占满空间之前将它们清除掉。清除Log有两种方法：

1.自动清除法

开放数据库选项 Trunc Log on Chkpt，使数据库系统每隔一段时间自动清除Log。此方法的优点是无须人工干预，由SQL Server自动执行，并且一般不会出现Log溢满的情况；缺点是只清除Log而不做备份。

2.手动清除法

执行命令“dump transaction”来清除Log。以下两条命令都可以清除日志：

dump transaction with truncate_only

dump transaction with no_log

通常删除事务日志中不活跃的部分可使用“dump transaction with trancate_only”命令，这条命令写进事务日志时，还要做必要的并发性检查，

SYBASE提供“dump transaction with no_log”来处理某些非常紧迫的情况，使用这条命令有很大的危险性，SQL Server会弹出一条警告信息。为了尽量确保数据库的一致性，你应将它作为“最后一招”。

以上两种方法只是清除日志，而不做日志备份，若想备份日志，应执行“dump transaction database_name to dumpdevice”命令。

四、管理庞大的事务

上例中的情况就可以分成两个或多个小的事务：

update tab_a set col_a=0 where col_b>x
go
dump transaction database_name with truncate_only
go
update tab_a set col_a=0 where col_b <=x
go
dump transaction database_name with truncate_only
go

这样，一个大的事务就被分成两个较小的事务。

(责任编辑：铭铭)

原文转自：www.ltesting.net

篇8：日志管理

“日志管理”包括自动备份的设置、备份数据的导入和删除等功能。

过去十年来，随着分布式系统的发展，日志数据管理起来更加复杂。如今，系统中可以容纳数以千计的服务器实例或者微服务容器，而所有这些实例或容器又会生成自己的日志数据。随着以云为基础的系统快速出现并占据主导地位，由机器所生成的日志数据呈爆炸性增长。而日志管理随之成为现代化IT运营中的重要任务，为包括调试、生产监控、性能监控、支持援助与故障查找之类的许多用例提供辅助支撑。

1. 设立策略

日志记录不可盲目，要对所记录的内容以及这样做的原因进行仔细考量。就像其他重要的IT组件一样，记录日志是需要策略的。在构建DevOps设置时，甚至只是发布一个单独的新功能时，都要确保做好日志记录的计划。没有明确的战略时，由于最终需要手动管理一个日渐庞大的日志数据集，识别重要信息的过程就会变得极为复杂。

在策划日志战略时，需要从自身角度考虑什么是最重要的，想要从日志中获得什么价值。你的计划应当包含：日志的记录方式与工具，数据托管的位置，以及最重要的——具体要寻找什么信息。

2. 日志数据的结构

除了要制定策略，还要考虑日志格式，这点也很重要。如果日志格式难以理解，想要识别日志，并从中总结出见解就很困难。无论对象是机器还是人类，日志的结构都应当清晰易懂。

管理者能够通过易读的日志更容易地找到故障，有时候还能使用日志管理服务对日志数据做进一步处理，让得出的见解更有深度，数据可视化更为优秀。两种常见的日志结构格式分别是JSON和KVP(主键配对)。两种日志数据均清晰易懂，适合人类理解，并且方便记录日志的软件解决方案从半结构化的格式中提取信息。

3. 日志数据的分离与集中

日志应当由系统自动收集并发送到集中的地点，与生产环境相分离。合并日志数据促进管理的有序与分析能力的增强，管理者能够有效地运行交叉分析，并识别不同数据源之间的关联。将日志数据集中化同时也降低了在自动扩展环境中损失日志数据的风险。

将日志数据转发到统一的位置后，系统管理员可以授权开发者、QA和支持团队访问日志数据，而无需赋予他们访问生产环境的权限。因而，这些团队可以使用日志数据调试，但不会有影响生产环境的风险。复制与独立化的日志数据也解决了相应的安全漏洞，避免攻击者删除日志数据，就算系统被破坏了，日志仍是安全的。

4. 端对端记录日志

为了简化定位故障的复杂度，在应用和系统层面获得更全局化的观点，应当在所有系统组件中监控并记录日志。大多数人都知道要记录服务器日志，比如Windows的安全日志。但是，在底层基础架构、应用层面和终端用户客户端记录所有相关的指标与事件也同样重要。

端对端日志记录让管理者得以从终端用户的角度了解系统性能，比如网络延迟、数据库事务处理延迟与页面加载时间。在这些地方清楚明了有利于提供无缝的用户体验。

5. 相关数据来源

将端对端日志统一记录到集中的地方，就可以动态聚合不同来源的各类数据流，比如来自应用的、服务器的、用户的和CDN的，从而分析得到相应的关键趋势与指标。这些关联的数据可以让管理者快速准确识别并理解导致系统故障的事件。例如，实时发现基础设施资源使用与应用出错率之间的关联，能够协助管理者在终端用户受到影响前先一步识别出异常与影响。

6. 使用唯一标识符

在调试、支持救援与分析中使用唯一的标识符非常有用。通过标识符可以追踪特定的用户会话，并精确地找出某个用户的活动。如果知道用户的唯一ID，就能搜索到某一时段用户的所有活动。一旦用户活动出现中断，可以通过追踪整个事务来查找。

7. 增加背景信息

将日志用做数据时，考虑每个数据点的背景情况非常重要。了解用户点击了一个按钮，也许比不上知道用户具体点击了“购买”按钮。增加额外的背景能够揭示购买模式。如果用户的购买请求出现错误，相应背景也能让问题更快解决。

8. 执行实时监控

服务中断会引发一系列不幸的结果，包括引发用户不满、购买意向流失与数据丢失。一旦出现生产层面的问题，在这个争分夺秒的时刻，实时监控非常重要。

除了发布简单的通知之外，能够实时分析问题与识别重要信息也同样重要。在日志数据中能够查看“实时轨迹”，使开发者和管理者能够在用户与应用或系统互动时分析日志事件。搜索并报告“实时轨迹”还能让支持团队对用户的问题进行分析与解决。

9. 使用日志来识别关键趋势

查找故障和调试只涉及了日志数据提供的表层信息。之前，查找日志曾因过于费劲，而被认为是查找信息的最终手段，而如今的日志服务可以让所有人——包括开发者、数据科学家都能从应用和系统中识别出有用的趋势与关键的见解。

10. 增强整个团队

只开放给高级技术团队的日志管理与分析服务严重限制了公司从日志数据中获得好处的机会。日志管理与分析工具应当能让开发者实时追踪调试，让管理者实时收到警报，让数据科学家集合数据并可视化，让支持团队执行实时搜索与筛选，而无需赋予他们访问生产环境的权限。

★ 数据大集中管理模式下数据同步技术探讨论文