什么是病毒？

病毒是附着于程序或文件中的一段计算机代码，它可在计算机之间传播。它一边传播一边感染计算机。病毒可损坏软件、硬件和文件。

病毒 (n.)：以自我复制为明确目的编写的代码。病毒附着于宿主程序，然后试图在计算机之间传播。它可能损坏硬件、软件和信息。

与人体病毒按严重性分类（从 Ebola 病毒到普通的流感病毒）一样，计算机病毒也有轻重之分，轻者仅产生一些干扰，重者彻底摧毁设备。令人欣慰的是，在没有人员操作的情况下，真正的病毒不会传播。必须通过某个人共享文件和发送电子邮件来将它一起移动。

什么是蠕虫？

与病毒相似，蠕虫也是设计用来将自己从一台计算机复制到另一台计算机，但是它自动进行。首先，它控制计算机上可以传输文件或信息的功能。一旦您的系统感染蠕虫，蠕虫即可独自传播。最危险的是，蠕虫可大量复制。例如，蠕虫可向电子邮件地址簿中的所有联系人发送自己的副本，那些联系人的计算机也将执行同样的操作，结果造成多米诺效应（网络通信负担沉重），使商业网络和整个 Internet 的速度减慢。当新的蠕虫爆发时，它们传播的速度非常快。它们堵塞网络并可能导致您（以及其他每个人）等很长的时间才能查看 Internet 上的网页。

蠕虫 (n.)：病毒的子类。通常，蠕虫传播无需用户操作，并可通过网络分发它自己的完整副本（可能有改动）。蠕虫会消耗内存或网络带宽，从而可能导致计算机崩溃。

蠕虫的传播不必通过“宿主”程序或文件，因此可潜入您的系统并允许其他人远程控制您的计算机。

什么是特洛伊木马？

在神话传说中，特洛伊木马表面上是“礼物”，但实际上藏匿了袭击特洛伊城的希腊士兵。现在，特洛伊木马是指表面上是有用的软件、实际目的却是危害计算机安全并导致严重破坏的计算机程序。最近的特洛伊木马以电子邮件的形式出现，电子邮件包含的附件声称是 Microsoft 安全更新程序，但实际上是一些试图禁用防病毒软件和防火墙软件的病毒。

特洛伊木马 (n.)：一种表面上有用、实际上起破坏作用的计算机程序。

一旦用户禁不起诱惑打开了以为来自合法来源的程序，特洛伊木马便趁机传播。

蠕虫和其他病毒如何传播？

实际上，所有病毒和许多蠕虫是无法传播的，除非您打开或运行了受感染的程序。

很多最危险的病毒主要通过电子邮件附件（随电子邮件一起发送的文件）传播。通常，可判断电子邮件是否包含附件，因为您将看到表示附件且包括附件名称的回形针图标。有些文件格式（例如，图片、用 Microsoft Word 写的信件或 Excel 电子表格）可能是每天都要通过电子邮件接收的。当打开受感染的文件附件（通常是双击附件图标以打开附件）时，就会启动病毒。

如果你对这两个参数有不清楚的地方，希望这篇文章可以扫除你的疑惑。

这两个参数对应于controlfile中不同的section。存放于完全不同的存储空间内。

MAXLOGHISTORY 对应于”LOG HISTORY ” section. 对应于view v$log_history & v$loghist，单位为log的个数

control_file_record_keep_time 对应于”ARCHIVED LOG” section, 对应于view v$archived_log 单位为keep的天数

这里所指的section可以从v$controlfile_record_section中查到

SQL> select TYPE,RECORDS_TOTAL,RECORDS_USED from v$controlfile_record_section
2 where type in (’LOG HISTORY’,'ARCHIVED LOG’);

TYPE RECORDS_TOTAL RECORDS_USED
——————– ————- ————
LOG HISTORY 907 526
ARCHIVED LOG 447 411

MAXLOGHISTORY 定义了controlfile中可以存储多少个log file的信息，可以从v$loghist, v$log_history中查到

control_file_record_keep_time 定义了controlfile中*至少*要keep多少天的archive log信息，可以从v$archived_log中查到。

我们来做下面这个简单的试验，大致可以明白这两个参数的含义

1. 重建controlfile maxloghistory=100, resetlogs open database，设置control_file_record_keep_time=0
SQL> select TYPE,RECORDS_TOTAL,RECORDS_USED from v$controlfile_record_section
2 where type in (’LOG HISTORY’,'ARCHIVED LOG’);

TYPE RECORDS_TOTAL RECORDS_USED
——————– ————- ————

LOG HISTORY 226 0
ARCHIVED LOG 111 0

这时候看到”LOG HISTORY”预先分配了226个record的空间，RECORDS_USED=0

“ARCHIVED LOG”预先分配了111个record的空间， RECORDS_USED=0

这里 “LOG HISTORY”不是如我们设置的maxloghistory=100那样预分配100个record的空间，是因为controlfile中分配空间以 block为单位的，这里block size为8k,一个record的大小为36 bytes,算下来差不多226个，如果你一开始指定maxloghistory=300,那么oracle会分配两个block，”LOG HISTORY”中与分配的RECORD数将为452左右（可能会有细小的误差）。所以更准确的说，创建controlfile时 maxloghistory的值指定了oracle将预分配多少个block给”LOG HISTORY” section

这里”ARCHIVED LOG”预分配了111个record的空间，”ARCHIVE LOG” section一条记录的大小为584bytes, 计算下来大约为8个block

2. 不断的产生archive log，看这两个存储空间如何扩展

SQL> begin
2 for i in 1..300 loop
3 execute immediate ‘alter system archive log current’;
4 end loop;
5 end;
6 /

PL/SQL procedure successfully completed.

在此过程中，一开始， 两者的RECORDS_USED都不断增加,因为有预留的空间可以使用

TYPE RECORDS_TOTAL RECORDS_USED
——————– ————- ————

LOG HISTORY 226 57
ARCHIVED LOG 111 57

当archive log section中RECORDS_USED到达111时，RECORDS_USED停止增加，log history仍然继续增长直到226

TYPE RECORDS_TOTAL RECORDS_USED
——————– ————- ————

LOG HISTORY 226 146
ARCHIVED LOG 111 111

最后300个archive log产生结束后，log history section存储226条信息，archived log存储111条信息，controlfile没有扩展,size保持不变

没有扩展的原因是我们设置了 control_file_record_keep_time＝0, controlfile没有必要扩展来保存archive log 信息，所以用完一开始保留的111个slot后就开始循环使用了。
TYPE RECORDS_TOTAL RECORDS_USED
——————– ————- ————

LOG HISTORY 226 226
ARCHIVED LOG 111 111

3.接下来我们设置control_file_record_keep_time＝１，继续生成300个archive logs

SQL> alter system set control_file_record_keep_time=1;

System altered.
SQL> begin
2 for i in 1..300 loop
3 execute immediate ‘alter system archive log current’;
4 end loop;
5 end;
6 /

PL/SQL procedure successfully completed.

在此过程中，一开始两个section就同时扩展了，LOG HISTORY section和ARCHIVED LOG section都扩展了到了原来的两倍大小（后面的试验中始终以２的倍数扩展）。controlfile size变大。

这里因为我们需要至少keep一天的archive log信息，所以archived log section自然要进行扩展。又因为这些archive log的信息同时也要在log history section中有记录，所以log history section也进行了扩展。
TYPE RECORDS_TOTAL RECORDS_USED
——————– ————- ————

LOG HISTORY 453 229
ARCHIVED LOG 223 114

两个section的RECORDS_USED持续增长， 当archived log的RECORDS_USED达到223时，这个section进行了第二次扩展，从223扩到了447，扩大到了原来的两倍大小

此时LOG HISTORY section中仍然有空间存放，所以不需要扩展该section
TYPE RECORDS_TOTAL RECORDS_USED
——————– ————- ————

LOG HISTORY 453 350
ARCHIVED LOG 447 235

当LOG HISTORY section中的 RECORDS_USED增长到453时，该section发生了第二次扩展，从453到907，扩大了一倍，此时ARCHIVE LOG section仍然后可用空间，并没有扩展

TYPE RECORDS_TOTAL RECORDS_USED
——————– ————- ————

LOG HISTORY 907 469
ARCHIVED LOG 447 354

所以从上面看出，两个section的扩展并没有什么关系，当自身需要扩展的时候就扩展一倍大小。MAXLOGHISTORY这个参数随着LOG HISTORY section的扩展而变大。
最后有一些常见的问题和解答：

1.为什么v$log_history和v$archived_log中记录数不一样

上面的试验已经解答了这个问题。这两个view对应于不同的东西，在controlfile中的存储空间也不同。

2. 为什么有时v$archived_log的keep的archive log 的天数大于control_file_record_keep_time所指定的天数

这种情况很常见，例如当系统某段时间很繁忙的时候，生成的archive log比较多，这时候为了keep指定天数的archive log，controlfile进行了大量的扩展，这部分空间扩展后不会回缩，而且是以两倍大小来扩展，所以当系统不是很繁忙的时候，就可以keep更多天的数据

control_file_record_keep_time指定的是至少要keep的天数，并不是说v$archived_log之只保留多少天的archive log

3. 为什么创建controlfile时指定的maxloghistory要小于实际的log history section预留的record数

这个问题前面也解释到了。空间分配以block为单位。准确的说创建controlfile时的maxloghistory规定了大致会预留多少个block，一个block大约可以存放226条记录

4. 如何dump controlfile

选自ixora，原文地址 http://www.ixora.com.au/notes/controlfile_dumps.htm

The contents of the current controlfile can be dumped in text form to a process trace file in the user_dump_dest directory using the CONTROLF dump. The levels for this dump are as follows.

For example, the following syntax could be used to get a text dump on the controlfile in the trace file of the current process showing all the controlfile record types but only the oldest and most recent of the circular reuse records.

oradebug setmypid oradebug dump controlf 3

Of course, the session must be connected AS SYSDBA to use the ORADEBUG facility. However, any session with the ALTER SESSION privilege can use the following event syntax to take the same dump.

alter session set events 'immediate trace name controlf level 3';

上面所说的各个section记录的size就是从dump文件中看出的，我使用的是level 3

***************************************************************************
LOG FILE HISTORY RECORDS
***************************************************************************
(blkno = 0×7b, size = 36, max = 907, in-use = 782, last-recid= 856)
Earliest record:
RECID #75 Recno 756 Record timestamp 08/13/06 23:42:26 Thread=1 Seq#=75 Link-Recid=74
Low scn: 0×0000.01865bef 08/13/06 23:42:26 Next scn: 0×0000.01865bf2
Latest record:
RECID #856 Recno 630 Record timestamp 08/14/06 00:03:45 Thread=1 Seq#=856 Link-Recid=855
Low scn: 0×0000.018665c7 08/14/06 00:03:45 Next scn: 0×0000.018665ca

***************************************************************************
ARCHIVED LOG RECORDS
***************************************************************************
(blkno = 0×86, size = 584, max = 895, in-use = 667, last-recid= 856)
Earliest record:
RECID #190 Recno 863 Record timestamp 08/13/06 23:44:23 Thread=1 Seq#=190
Flags:
Resetlogs scn and time scn: 0×0000.0186593c 08/13/06 23:32:41
filename /oracle/GBPGW/archive/BABY/BABY_190.arc
Low scn: 0×0000.01865d4a 08/13/06 23:44:23 Next scn: 0×0000.01865d4d 08/13/06 23:44:23
Block count=1 Blocksize=512
Latest record:
RECID #856 Recno 634 Record timestamp 08/14/06 00:03:45 Thread=1 Seq#=856
Flags:
Resetlogs scn and time scn: 0×0000.0186593c 08/13/06 23:32:41
filename /oracle/GBPGW/archive/BABY/BABY_856.arc
Low scn: 0×0000.018665c7 08/14/06 00:03:45 Next scn: 0×0000.018665ca 08/14/06 00:03:45
Block count=1 Blocksize=512

增量备份(incremental backup)

　　增量备份比完全备份快得多。在进行增量备份，只有那些在上次完全或者增量备份后被
修改了的文件才会被备份。正是由于这个原因，增量备份所需时间仅为完全备份的几分之一
。为了确认一个文件是否在上次完全备份后被修改，备份软件会检查一个叫做归档位（arch
ive bit）的设置项。

　　当一个文件以任何形式被更改或者从一个位置拷贝到了另一个位置，归档位都会记录下
这一变化，以便这个文件在下次备份时被包含在内。完全备份在进行前不会关心这些文件的
归档位是否已经被设置，不过完全备份会在完成后清除归档位。任何在随后时间里被修改过
的文件又会在归档位中记录下来。

　　差量备份（differential backup）

不会在备份完成后清除归档块，而增量备份会在完成
后清除归档块，这样就能避免有些文件不必要地再次被备份。使用归档块还能使用户真实地
查看到那些文件需要备份。

　　速度更快的备份也需要付出有些代价——在这个情况下， 就是恢复的时间。当从增量备
份里恢复时，用户需要最近一次的完全备份和自此以后的所有增量备份。例如，如果用户在
星期五进行了完全备份，然后在星期一、星期二、星期三进行了增量备份，然后服务器在星
期四早上崩溃了，那么用户就需要4盒磁带 － 星期五的完全备份盒星期一、星期二、星期三
的增量备份。

　　差量备份

　　差量备份和增量备份往往容易被弄混淆，不过两者之间有一个明显的区别。增量备份会
备份那些自从上次完全备份或者增量备份之后被修改过的文件，差量备份会备份自从上次完
全备份后被修改过的文件。从差量备份中恢复也是很快的，因为只需要两份磁带——最后一
次完全备份和最后一次差量备份。

　　差量备份在那些拥有充足空间和时间来进行备份的环境中很适用。在进行差量备份时，
软件会寻找那些设置了归档块的文件，然后仅仅备份这些文件。

　　上面已经讲过了，差量备份拷贝任何自从上次完全备份经过了修改的文件，而完全备份
会清除归档块中的信息，差量备份不会改动归档块的状态。这样做的优点是恢复时只需要2份
磁带就可以进行完全的复原。不利之处是，每次进行差量备份，都非常有可能把那些在上次
完全备份后被修改了，不过在上次差量备份后没有被修改过的文件备份不止一次。

将db_recovery_file_dest参数设置为空，可以停用闪回恢复区。如果已经启用flashback database，则不能取消闪回恢复区。

SQL> alter system set db_recovery_file_dest=''; alter system set db_recovery_file_dest=''

* 第 1 行出现错误: ORA-02097: 无法修改参数, 因为指定的值无效 ORA-38775: 无法禁用快速恢复区 - 闪回数据库已启用

所以，必须先禁用flashback database，才能取消闪回恢复区。

SQL> shutdown immediate;

SQL> startup mount;

SQL>alter database flashback off;

SQL> alter database open;

SQL> alter system set db_recovery_file_dest='';

设置闪回恢复区后，如果没有设置过log_archive_dest_n参数，则归档日志默认是保存到该(闪回)区域的，所以，取消了闪回功能后需要设置log_archive_dest_n参数来更改归档文件的存放位置。

1、必须建立一个新的undo tablespace，大小设为你想要的值

2、SQL> alter system set undo_tablespace=undo_rbs1;

3、SQL> drop tablespace undo_rbs0 including contents;

如果drop旧的undo tablespace的时候出错，ORA-30013 : undo tablespace '%s' is currently in use. 这错误就是说在旧的undo tablespace中还存在没有commit或者rollback的事务，那么就需要等待这些事务完成。

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

xhost:  unable to open display ":0.0"

when running a program, you probably need to add the user to the X server access list.

You can add a user to the X server access list with

# xhost +local:username

This allows "username" to connect to the local running X server.

我在使用vsftpd假设ftp服务器时，遇到了启动正常，但无论如何设置都出现不能连接，报错：530 login incorrect。已确定用户名和密码正确。

解决方法：查看/var/log/message文件，看到（时间）vsftpd:pam_listfile(vsftpd:auth):Refused user oracle for service vsftpd的信息，然后再查看/etc/pam.d/vsftpd文件，发现有这么一行

auth required pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed

把其中的sense=deny改为sense=allow

重启vsftpd即可。

转载自：http://space.itpub.net/html/27/4227-69239.html

在导入的时候如果采用表和索引分步导入的方式可能会出现问题。

看一个简单的例子：

在近代历史上，日志文件系统被认为十分奇特，主要是处于研究阶段。而如今，日志文件系统（ext3）已经成为 Linux 的缺省文件系统。本文向大家揭示了日志文件系统背后的一些思想，以及在电源故障或系统崩溃时，如何提供更好的完整性。此外本文还介绍了现行的几种日志文件系统和下一代日志文件系统。

定义日志文件系统的方法有很多种，但是让我们抓住要点。日志文件系统就是专为那些厌倦了一直盯着启动时 fsck（即文件系统一致性检查）的人而设计的（日志文件系统同样适用于希望文件系统具有故障恢复能力的群体）。如果系统采用传统的未提供日志功能的文件系统，那么操作系统在检测到系统为非正常关机时，会使用 fsck 应用程序执行一致性检验。该应用程序会扫描文件系统（这要花费很长的时间），并修复任何可安全修复的问题。而在某些情况下，当文件系统损坏严重时，操作系统会启动到单用户模式，由用户进行进一步的修复。

那么现在您应该清楚日志文件系统针对的是哪类人群了，但是他们是如何取缔 fsck 的呢？笼统地说，日志文件系统就是通过维护一份日志来防止文件系统崩溃。所谓日志就是一种特殊的文件，它会在一个循环的缓冲区内记录文件系统的修改，然后将其定期提交到文件系统。一旦系统发生崩溃，日志文件就会起到一个检查点的作用，用于恢复未保存的信息，防止损坏文件系统元数据。

总之，日志文件系统就是一种具有故障恢复能力的文件系统，它利用日志来记录尚未提交到文件系统的修改，以防止元数据破坏（请参见图 1）。但是如众多其他 Linux 解决方案一样，日志文件系统有多种方案供您选择。下面就让我们一起简短回顾一下日志文件系统的历史，然后再看一看现行的几种文件系统，看看它们之间有什么区别。

fsck 问题

更麻烦的是，为了确保文件系统元数据的正确性（即使未检测到损坏），操作系统会自动启动 fsck 进程。因此，避免对文件系统进行一致性检验正是需要改进的地方。

什么是元数据？

元数据 指磁盘上的数据的管理结构。它表示文件的创建与删除、目录的创建与删除、扩充文件、截取文件等。

1 使数据库处于ARCHIVELOG模式

alter database archivelog;//----这要在mount模式下才能执行

2 获取最早的联机日志序列号

archive log list

3 将要备份的表空间设为热备份模式
ALTER TABLESPACE tablespace_name BEGIN BACKUP;

4 使用操作系统命令备份改表空间的datafile

如果是使用ASM---raw，那么就要使用rman（文件级cp）或者dd（设备级cp）

5 取消该表空间的热备份模式

ALTER TABLESPACE tablespace_name END BACKUP;

6 如还有其他要备份的表空间，重复3-5

7 强制日志切换
　　
ALTER SYSTEM SWITCH LOGFILE ;

8备份所有归档日志文件

9 备份control file
　　
ALTER DATABASE BACKUP CONTROL FILE TO 'filespecif' ;