确认不在需要的日志需要进行清理:
$ORACLE_BASE/admin/<SID>/bdump/alert_<sid> echo > alert_<sid>log
$ORACLE_HOME/network/log/listenerlog: echo >listenerlog
$ORACLE_BASE/admin/udump/trc: rm –rf trc
清除数据库日志语句
--清除sqlserver 2000/2005 数据库日志
替换下红字部分数据库名称
declare @databasename varchar(15)
select @databasename='hdjjgl_journal'
DUMP TRANSACTION @databasename WITH NO_LOG
BACKUP LOG @databasename WITH NO_LOG
DBCC SHRINKDATABASE(@databasename)
或者
USE 数据库名
DUMP TRANSACTION 数据库名 WITH NO_LOG
BACKUP LOG 数据库名 WITH NO_LOG
DBCC SHRINKFILE(2)
--清除sqlserver 2008 数据库日志 ,执行两遍
替换下红字部分数据库名称,建立datalogbak清楚的日志备份文件夹,注意路径自定义。
use gdzjg_journal
declare @databasename varchar(100)
declare @databasenamelog varchar(100)
declare @databasenamedir varchar(100)
select @databasename='gdzjg_journal'
select @databasenamelog=@databasename+'_log'
select @databasenamedir='g:\datalogbak\'+@databasename
BACKUP LOG @databasename to disk=@databasenamedir
DBCC SHRINKFILE (@databasenamelog,1)
或者
ALTER DATABASE 数据库名称SET RECOVERY SIMPLE
ALTER DATABASE 数据库名称SET RECOVERY FULL
DBCC SHRINKDATABASE(数据库名称,0)
sqlserver 2000、2008会保存所有的数据库 *** 作过程,将指令保存在ldf文件中,如果误删除数据,想恢复数据的话,可以通过Lumigent Log Explorer For SQLServer 软件分析ldf文件,可以看到所有执行过的insert、update、delete数据,导出来再逆向执行即可,本人曾经用过一回,确实奏效。
1、sql server 2000清理数据库日志
USE 数据库名
DUMP TRANSACTION 数据库名 WITH NO_LOG
BACKUP LOG 数据库名 WITH NO_LOG
DBCC SHRINKFILE(2)
SHRINKFILE(2),后面的2是file_id,可以在当前数据库用select from sysfiles看得到,看数据库的log文件的fileid是多少,正常情况下log的ldf文件是2,mdf文件的fileid是1。
这个查询语句可以随时执行,不影响数据库的运行。
sql server 2005、2008清理数据库日志
USE 数据库名
ALTER DATABASE 数据库名 SET RECOVERY SIMPLE
ALTER DATABASE 数据库名 SET RECOVERY FULL
DBCC SHRINKDATABASE(数据库名,0)
这个查询语句可以随时执行,不影响数据库的运行。
清理ldf的 *** 作可以使用sql server代理,每天自动执行一次,就不怕文件增长撑爆硬盘了。
2、一般mdf用不着收缩,收缩多了容易产生文件碎片,因为delete数据之后,mdf文件中可用页面空间会保留在那里,等下次有新数据进来时,会继续使用。如果实在要清理,可以参考下面的语句:
sql server 2000、2005、2008 收缩mdf文件
DBCC SHRINKDATABASE(数据库名)
DBCC SHRINKFILE(1,0)
DBCC UPDATEUSAGE(0)
执行上述 *** 作后,你会发现mdf的文件减少了,ldf的文件增大了,再用上面1的日志清理 *** 作一次即可。
3、最后再附送一个查看数据表的行数、占用文件空间、存储情况的查询语句
-- drop table #test
create table #test(
name varchar(50),
rows int,
reserved varchar(20),
data varchar(20),
index_size varchar(20),
unused varchar(20)
)
set nocount on
insert into #test
EXEC sp_MSforeachtable @command1="sp_spaceused ''"
select from #test order by cast(replace(reserved,'KB','') as int) desc
VMware的vCenter Server数据库就如同VMware的存储库。在vCenter里,几十个表格存储着资源、集群、VMware分布式资源调度程序、快照、VMware ESX主机、虚拟机、警告、性能参数、任务和事件等信息。
问题是如果环境里拥有许多VMware主机服务器和虚拟机,数据库增长得非常大。不过增长的空间主要来自少数几个包括任务、事件和历史性能数据的表格(参见下面的描述)。从vCenter Server数据库删除无关的任务和事件能节约空间、提升系统性能、加速备份和最小化数据库崩溃的概率。在本文中,TechTarget中国的特约虚拟化专家Eric Siebert将介绍如何使用微软的SQL Server从vCenter数据库删除不需要的信息。
*** 作vCenter表格数据
不过在清理文件之前,你应该明白vCenter Server的表格数据。下面是有关这些表格的信息类型简要。
任务信息。这个表格包括在vCenter Server执行的所有任务的信息。
VPX_TASK
事件信息。这个表格包括所有发生在vCenter Server的事件的信息。对于每一个事件,VPX_EVENT表格里占有一行,由于EVENT_ID字段,有一行或更多行在VPX_EVENT_ARG。
VPX_EVENT
VPX_EVENT_ARG
历史参数。这些表格包括vCenter Server所管理的主机与虚拟机的性能记数信息。对于vCenter Server 20x服务器来说,这个信息存储在单个的VPX_HIST_STAT表格里。但在vCenter Server 25里,这种方式改变了:每天的性能数据存储在VPX_HIST_STAT1里,然后融入VPX_HIST_STAT2计算每周数据,最后,融入VPX_HIST_STAT4计算每年数据。此外,有四个样本时间表格用于VMware迁移技巧——白皮书历史性能表格。
VPX_HIST_STAT (VC 20x)
VPX_HIST_STAT1 (VC 25)
VPX_HIST_STAT2 (VC 25)
VPX_HIST_STAT3 (VC 25)
VPX_HIST_STAT4 (VC 25)
VPX_SAMPLE_TIME1 (VC 25)
VPX_SAMPLE_TIME3 (VC 25)
VPX_SAMPLE_TIME3 (VC 25)
VPX_SAMPLE_TIME4 (VC 25)
使用vCenter Server清除数据
通过更改参数间隔配置,能间接地使用vCenter Server清除数据。当你更改某个间隔,只有关于这个间隔的数据被清除。例如,如果你只更改每周间隔,就清除了每周数据,但没有清除每天、每月和每年的数据。你也能更改所收集的数据或者禁用间隔,这将减少VPX_HIST_STAT表格的大小。
有几大原因需要删除这个数据。首先是为了降低在数据库服务器上使用的空间数量。在大型环境里,这样的的数据库很容易就增长到20GB,虽然这可能对于运行在大型本地磁盘上的SQL Server不成问题,但在使用不同存储区域网络的磁盘空间的数据库服务器上就有问题。
第二个原因是性能。数据库越大,搜寻数据和完成如更新索引这样的数据库 *** 作就更花费时间。最后,拥有的数据越少,数据库越有效率,发生崩溃的概率也越小。备份数据库的时间也更少。
底线是问问自己是否真的需要那么多的历史任务和历史事件数据。你在一年前检查过新年数据吗?旧的性能数据对于偶尔的定点有价值。不过如果不需要这种功能,就清除旧数据。同样,首先考虑不要收集数据。你可能只收集每天和每周的数据用于故障检修的目的,并禁用比较久的每月和每年的数据。
检查表格大小
使用SQL命令,能检查表格的大小。对于SQL数据库来说,使用SQLPlus或另外的SQL客户端在登录到数据库,使用以下的SQL命令:
select count () from VPX_EVENT
这个命令显示了表格里的行数(或记录)。对于其他表格,更改表格名称查看。
select num_rows avg_row_len from user_tables where table_name = 'VPX_EVENT'
这个命令以字节形式显示表格正在使用的磁盘空间数量,不包括剩余的表格空间。
select bytes from user_segments where segment_name = 'VPX_EVENT'
这个命令以字节形式显示表格正在使用的磁盘空间数量,包括剩余的表格空间。
对于SQL Servers,通过以下命令,能使用SQL Query Analyzer工具(作为SQL server的一部分安装)。
在Query窗口输入:
use
然后输入:
EXEC sp_spaceused
接下来点击Execute Query图标或按F5。这将运行sp_spaceused存储程序(本质上是一个SQL服务器脚本),显示这个表格的信息,包括正在使用的行数、保存在表格里以千字节显示的磁盘空间数量以及数据所占据的表格空间的数量。想查看其他表格的这些信息,只需要用其他表格名称输入上面的命令。
现在我们知道了表格的情况和如何决定它们的大小,我们就能清除数据了。在这系列的下一篇文章中,我们将介绍如何使用VMware所提供的SQL脚本清除数据。
一、数据库表清理
1 wordpress数据库表
wp_commentmeta: 用于保存评论的元信息,在将评论放入回收站等 *** 作时会将数据放入此表,Akismet等插件也会生成此表的数据。此表不太重要
wp_comments: 用于保存评论信息的表
wp_links: 用于保存用户输入到Wordpress中的链接(通过Link Manager)的表
wp_options: 用于保存Wordpress相关设置、参数的表,里面包括了大量的重要信息
wp_postmeta: 用于保存文章的元信息(meta)的表
wp_posts: 用于保存你所有的文章相关信息的表,非常的重要。一般它存储的数据是最多的
wp_terms: 文章和链接分类以及文章的tag分类可以在表里找到
wp_term_relationships: 日志与wp_terms中的类别与标签联合起来共同存储在wp_terms_relationships表中。类别相关链接也存储在wp_terms_relationships中
wp_term_taxonomy: 该表格对wp_terms表中的条目分类(类别、链接以及标签)进行说明
wp_usermeta : 用于保存用户元信息(meta)的表
wp_users:用于保存Wordpress使用者的相关信息的表
2 清理涉及到的表
更换主题,删除插件会在将数据留在数据库中,在卸载后无法被清理。除此之外,在由于一些 *** 作,会导致数据库的冗余,比如已经没有的评论,不应该在评论元数据表中有记录,由于没有外键的约束,这些记录没有被删除,会造成数据的冗余。本文的宗旨是删除掉不必要的数据库内容,提高wordpress的效率
在此,主要涉及到一下几张表:wp_options,wp_posts,wp_postmeta,wp_commentmeta
注意清理之前进行备份
3 wp_options的清理
wp_options 这个数据表是wordpress设置的全局数据,这个表会经常有数据膨胀。主要原因是:
(1)以前用过的一些插件、主题在删除之后没有进行设置的清理,造成残留数据
(2)占用数据的大户–RSS缓存,后台的数据调用竟然会放到数据库里面
处理方法:
①网上对RSS处理方法有两种一个是修改后台的文件直接不去调用,这个是我不喜欢的毕竟修改了程序,其实这个很容
易忘记WP升级是太频繁的哪次更新覆盖了新文件还是照样缓存另外一种就是在配置文件里面填写define(‘MAGPIE_CACHE_ON’, ’0′); 这个是管用的,添加以后后台首页的调用明显变慢
②使用插件clean options
③费力但是简单的清除方法:删除wp_options表,会删除一些设置,需要重新设置wordpress,推荐新手使用
TRUNCATE TABLE wp_options;
4wp_posts清理
wordpress的文章有好多:wp_posts表中包括
文章种类:文章、修订版本、页面、文章的附件、菜单
其中每种文章又会有很多状态:继承、发布、私有、草稿、自动草稿、回收站中
冗余原因:
(1)在博主写文章的时候,系统会保存很多的中间状态,在文章发布之后其很多的中间状态没有被删除
解决办法:
①使用插件:WP Cleaner,使用插件的好处就是有保护机制,无论怎么 *** 作都无法影响已发布的贴子,请放心使用
②自己动手删除,数据库中的标志删除文章,注意备份
说明:wp_posts的重要字段含义:
post_type:文章类型,post表示为文章,revision表示为修订版本,page为页面,attachment是文章的附件信息,nav_menu_item是菜单。这里我们需要的是文章、页面、和菜单
post_status:文章状态,inherit是继承的附件和文章的附带信息,publish是已经发布、private是私有的,draft是草稿,auto-draft是自动草稿,trash是在回收站。这里我们需要的是publish的状态的
这里我们主要是要 已经发布的文章、页面和菜单,除此之外的都可以删除,当然可以根据自己的需求选择删除哪些
DELETE FROM wp_posts
WHERE NOT(post_status = ‘publish’ AND post_type IN(‘post’,'nav_menu_item’,’ page’));
③去除WP保存修订版本的功能
WordPress默认的功能并不都是我们想要的,比如修订版本历史对于大多数人来说是无用的鸡肋功能。所以我么需要禁止一些博客功能,来达到较为符合个
人要求的博客应用。对于高手来说,可以直接修改程序的配置文件,来禁止相关功能。对于我等程序小白来说还是利用插件是最佳的选择
推荐中文插件SuperSwitch来关闭一些我们不需要的博客功能。这个插件可以关闭自动保存和修订历史版本,还可以关闭博客程序、主题、插件的自动更新。功能非常强大, *** 作及其简单。用SuperSwitch禁止了保存修订版本之后,文章序号就不会断得太厉害了
5wp_postmeta清理
wp_postmeta是文章的元信息表,其数据是系统或者插件使用
冗余原因:
(1)文章被删除之后,其在wp_postmeta中的数据理应被删除,在系统中多数情况是系统自动删除,但是由于人为删除文章,系统不知道被删除,就不会删除wp_postmeta表中的数据,造成冗余
(2)很多主题、插件没有做好及时清除的工作
解决办法:
① 手动删除
规矩删除
删除文章中不存在文章的元信息
DELETE FROM wp_postmeta WHERE post_id NOT IN (SELECT post_id FROM wp_posts);
安全删除
删除_edit_lock和_edit_last条目是安全的,所以这里给出SQL语句
DELETE FROM wp_postmeta WHERE meta_key = ‘_edit_lock’;
DELETE FROM wp_postmeta WHERE meta_key = ‘_edit_last’;
风险删除
除了这两条还执行了一些其他语句由于有些风险:自己酌情考虑
DELETE FROM wp_postmeta WHERE meta_key = ‘_wp_old_slug’;
DELETE FROM wp_postmeta WHERE meta_key = ‘_revision-control’;
DELETE FROM wp_postmeta WHERE meta_value = ‘{{unknown}}’;
特殊插件删除
postnav插件会记录每个文章的访问数,如果不需要,可以删除
DELETE FROM wp_postmeta WHERE meta_key = ‘views’;
特殊 *** 作删除
在WordPress的后台上传或者附件后会在wp_postmeta中生成_wp_attached_file和_wp_attachment_metadata两个项,wp_posts也会记录附件的信息。如果使用FTP工具上传文件,表中就不会有这些信息
DELETE FROM wp_postmeta WHERE meta_key = ‘_wp_attached_file’;
DELETE FROM wp_postmeta WHERE meta_key = ‘_wp_attachment_metadata’;
洁癖删除
这几条条语句执行完毕能够删除掉95%以上的数据,算的上是极限优化了,最后考虑到这个数据表并不是很重要,有洁
净癖的人可以尝试清空这个表,当然我测试清空表会让一些原本的数据丢失
TRUNCATE TABLE wp_postmeta;
6 wp_commentmeta清理
冗余原因:
(1)评论被删除之后,其在wp_commentmeta中的数据理应被删除,在系统中多数情况是系统自动删除,但是由于人为删除文章,系统不知道被删除,就不会删除wp_commentmeta表中的数据,造成冗余
(2)很多主题、插件没有做好及时清除的工作
解决办法:
一下语句去除没有用的数据,如果评论中没有此条评论,那么在wp_commentmeta也没有意义,好像wordpress在清空回收站的时候会删除wp_commentmeta相应的数据。如果不出意外,下面的 *** 作我们应该不需要做
DELETE FROM wp_comments WHERE comment_approved = ‘trash’;
DELETE FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments);
在wp_commentmeta里面会记录评论被删除的时间,这些信息用处不是很大,当评论被从回收站删除之后,这些删除的时间意义就不是很大,就可以删除了,所以用下面的语句一样达到删除的目的
DELETE FROM wp_commentmeta WHERE meta_key LIKE ‘%trash%’;
如果直接全部删除wp_commentmeta,影响不会太大,这里面不会涉及重要的数据
TRUNCATE TABLE wp_commentmeta
7 总结
其实大部分无用的数据均在这几张表中,清理过后应该不会又太多的冗余数据了。但这里没有针对特殊插件或主题做数据库清理,有时这些插件和主题会悄悄动了一些数据库表,这样给清理带来很大难度,需要看代码才知道哦
二、数据库表优化
原理:数据库优化不
涉及数据的删除,是将数据库的表的状态调整好。在使用phpmyadmin时候,或许您会看到数据库表后面有多余xxMB的字样,这个指的是那些已经分配
给当前表但是却没有使用的空间。这个多余是没有什么害处的,他不会占用你的空间。当删除一个表的一部分记录时,这些记录仍然保持在一个linked
list 中,当插入新数据时会再次使用这些老纪录的位置。所以删除纪录会闲置一些空间造成你说的“多余”
优化:
(1)在phpmyadmin手动 优化或者修复表即可
(2)运行SQL:
OPTIMIZE TABLE wp_commentmeta;
OPTIMIZE TABLE wp_comments;
OPTIMIZE TABLE wp_links;
OPTIMIZE TABLE wp_options;
OPTIMIZE TABLE wp_postmeta;
OPTIMIZE TABLE wp_posts;
OPTIMIZE TABLE wp_terms;
OPTIMIZE TABLE wp_term_relationships;
OPTIMIZE TABLE wp_term_taxonomy;
OPTIMIZE TABLE wp_usermeta;
OPTIMIZE TABLE wp_users;
(3)插件:Optimize DB
我是使用SQL语句进行清理与优化的,附我的优化SQL语句(我的表前缀是wp1):
DELETE FROM wp1_posts WHERE NOT(post_status = ‘publish’ AND post_type IN(‘post’,'nav_menu_item’,’ page’));
DELETE FROM wp1_postmeta WHERE meta_key in (‘_edit_lock’,
‘_edit_last’, ‘_wp_old_slug’, ‘_revision-control’, ‘{{unknown}}’,
‘_wp_attached_file’, ‘_wp_attachment_metadata’);
DELETE FROM wp1_postmeta WHERE post_id NOT IN (SELECT id FROM wp1_posts);
DELETE FROM wp1_comments WHERE comment_approved like ‘%trash%’;
DELETE FROM wp1_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp1_comments);
OPTIMIZE TABLE wp1_commentmeta;
OPTIMIZE TABLE wp1_comments;
OPTIMIZE TABLE wp1_links;
OPTIMIZE TABLE wp1_options;
OPTIMIZE TABLE wp1_postmeta;
OPTIMIZE TABLE wp1_posts;
OPTIMIZE TABLE wp1_terms;
OPTIMIZE TABLE wp1_term_relationships;
OPTIMIZE TABLE wp1_term_taxonomy;
OPTIMIZE TABLE wp1_usermeta;
OPTIMIZE TABLE wp1_users;
以上就是关于oracle数据清理数据库日志全部的内容,包括:oracle数据清理数据库日志、清理数据库碎片SQL语句、如何使用SQL命令删除vCenter Server里的陈旧数据等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)