vim命令模式下tab补全的问题
Tuesday, March 30, 2010
今天终于搞定了困扰自己vim问题
什么问题呢，说出来有点好笑，在命令模式下打:tabnew c:\，然后按tab，正常的话会补全路径，可是家里的laptop windows 7上vim，死活不出来，显示的是:tabnew c:\^I。google了半天也找不到方法。
今天还是不死心，再google了一把，算是解决了，可是还是不知道原理，不管了，能用就好了。
解决的方法是：
1、在_vimrc里面加上
set wildmenu
set wildmode=longest:full
进入VIM，敲入:im<TAB>，VIM会在命令上面显示出im开始的命令，黄色是选择高亮：
imap imapclear imenu
:im
这时可以继续敲入后续字母再按<TAB>补全，或者用<LEFT>/<RIGHT>或<C-n> /<C-p>在列表中前进或后退。
同样对文件名补全，在VIM里输入:edit ./<TAB>会得到当前目录下的所有文件和子目录：
_vim/ _vimrc addins.v6/ addins.v7/ after/ others.vimrc/ plugins/ plugins.extern/ >
:edit ./
2、再把上面2句话注释掉
大功告成，命令行模式下tab补全又神奇般的回来了。
SQL Server Databases性能计数器对象
Monday, March 22, 2010
SQL Server Databases 对象2008
SQL Server 中的 SQLServer:Databases 对象提供了计数器，来监视大容量复制操作、备份和还原吞吐量以及事务日志活动。监视事务及事务日志确定数据库中进行的用户活动数量及事务日志的饱满程度。用户活动数量可以确定数据库的性能并影响日志大小、锁和复制。监视低级日志活动以测量用户活动和资源使用情况，有助于查明性能瓶颈。
可以同时监视 Databases 对象的多个实例，每个实例代表一个数据库。
下表说明了 SQL Server Databases 计数器。
| SQL Server Databases 计数器 | 说明 |
| Active Transactions | 数据库的活动事务数。 |
| Backup/Restore Throughput/sec | 每秒数据库的备份和还原操作的读取/写入吞吐量。例如，并行使用多个备份设备或使用更快的设备时，可以测量数据库备份操作性能的变化情况。数据库的备份或还原操作的吞吐量可以确定备份和还原操作的进程和性能。 |
| Bulk Copy Rows/sec | 每秒大容量复制的行数。 |
| Bulk Copy Throughput/sec | 每秒大容量复制的数据量 (KB)。 |
| Data File(s) Size (KB) | 数据库中所有数据文件的累计大小 (KB)，包括任何自动增长。监视此计数器非常有用，例如可以确定 tempdb 的准确大小。 |
| DBCC Logical Scan Bytes/sec | 每秒数据库命令控制台 (DBCC) 语句的逻辑读取扫描字节数。 |
| Log Bytes Flushed/sec | 刷新的日志字节总数。 |
| Log Cache Hit Ratio | 日志缓存所满足的日志缓存读取数所占的百分比。 |
| Log Cache Reads/sec | 每秒通过日志管理器缓存执行的读取数。 |
| Log File(s) Size (KB) | 数据库中所有事务日志文件的累计大小 (KB)。 |
| Log File(s) Used Size (KB) | 数据库中所有日志文件的累计已用大小。 |
| Log Flush Wait Time | 刷新日志的总等待时间（毫秒）。 |
| Log Flush Waits/sec | 每秒等待日志刷新的提交数目。 |
| Log Flushes/sec | 每秒日志刷新数目。 |
| Log Growths | 数据库事务日志增长的总次数。 |
| Log Shrinks | 数据库事务日志收缩的总次数。 |
| Log Truncations | 数据库事务日志截断的总次数。 |
| Percent Log Used | 日志中已用空间所占的百分比。 |
| Repl.Pending Xacts | 发布数据库事务日志中已做复制标记但尚未传递到分发数据库的事务数。 |
| Repl. Trans. Rate | 每秒从发布数据库事务日志中读出并传递到分发数据库的事务数。 |
| Shrink Data Movement Bytes/sec | 每秒由自动收缩操作或者 DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 语句移动的数据量。 |
| Transactions/sec | 每秒为数据库启动的事务数。 |
| Write Transactions/sec | 在上一秒钟内写入数据库并提交的事务数。 |
SQL Server Databases 对象2005
SQL Server 中的 SQLServer:Databases 对象提供了计数器，来监视大容量复制操作、备份和还原吞吐量以及事务日志活动。监视事务及事务日志确定数据库中进行的用户活动数量及事务日志的饱满程度。用户活动数量可以确定数据库的性能并影响日志大小、锁和复制。监视低级日志活动以测量用户活动和资源使用情况，有助于查明性能瓶颈。
可以同时监视 Databases 对象的多个实例，每个实例代表一个数据库。
下表说明了 SQL Server Databases 计数器。
| SQL Server Databases 计数器 | 说明 |
| Active Transactions | 数据库的活动事务数。 |
| Backup/Restore Throughput/sec | 每秒数据库的备份和还原操作的读取/写入吞吐量。例如，并行使用多个备份设备或使用更快的设备时，可以测量数据库备份操作性能的变化情况。数据库的备份或还原操作的吞吐量可以确定备份和还原操作的进程和性能。 |
| Bulk Copy Rows/sec | 每秒大容量复制的行数。 |
| Bulk Copy Throughput/sec | 每秒大容量复制的数据量 (KB)。 |
| Data File(s) Size (KB) | 数据库中所有数据文件的累计大小 (KB)，包括任何自动增长。监视此计数器非常有用，例如可以确定 tempdb 的准确大小。 |
| DBCC Logical Scan Bytes/sec | 每秒数据库命令控制台 (DBCC) 语句的逻辑读取扫描字节数。 |
| Log Bytes Flushed/sec | 刷新的日志字节总数。 |
| Log Cache Hit Ratio | 日志缓存所满足的日志缓存读取数所占的百分比。 |
| Log Cache Reads/sec | 每秒通过日志管理器缓存执行的读取数。 |
| Log File(s) Size (KB) | 数据库中所有事务日志文件的累计大小 (KB)。 |
| Log File(s) Used Size (KB) | 数据库中所有日志文件的累计已用大小。 |
| Log Flush Wait Time | 刷新日志的总等待时间（毫秒）。 |
| Log Flush Waits/sec | 每秒等待日志刷新的提交数目。 |
| Log Flushes/sec | 每秒日志刷新数目。 |
| Log Growths | 数据库事务日志增长的总次数。 |
| Log Shrinks | 数据库事务日志收缩的总次数。 |
| Log Truncations | 数据库事务日志截断的总次数。 |
| Percent Log Used | 日志中已用空间所占的百分比。 |
| Repl.Pending Xacts | 发布数据库事务日志中已做复制标记但尚未传递到分发数据库的事务数。 |
| Repl. Trans. Rate | 每秒从发布数据库事务日志中读出并传递到分发数据库的事务数。 |
| Shrink Data Movement Bytes/sec | 每秒由自动收缩操作或者 DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 语句移动的数据量。 |
| Transactions/sec | 每秒为数据库启动的事务数。 |
SQL性能监控重要性能指标的list
贴一下DBA同事的运维经验
对于运维人员来说，学会查看性能计数器是一个重要的技能手段
通过性能计数器，可以帮助我们缩小排查范围，快速定位问题原因
从系统角度来看，无外乎内存、磁盘、cpu等
（请注意我的次序，现在的cpu已几乎不成为服务器的瓶颈；cpu的性能问题，往往是由前2者引发的。磁盘性能问题，也有可能是内存引起的哦）
下面说说几个最主要的计数器：
----- ----- ----- ----- 以下部分摘自网上，红字部分是我个人的理解，欢迎指教与讨论 ----- ----- ----- -----
Memory: Pages/sec
描述：这个计数器记录每秒中RAM和硬盘上虚拟内存交换（换出+换入）的页数。
范围：如果SQL Server是这个服务器上唯一主要运行的应用，则这个值应该在0-20之间。当超出这个范围，建议增加物理内存。
（即越低越好，对维护人员来说，呵呵）
Memory: Available Bytes
描述：服务器可用的物理内存字节数
范围：这个计数器的平均值应该>5MB，SQL Server 2005 会试图一直维持4-10MB这个范围。当小于建议范围的时候，可以尝试提高SQL Server的性能，包括增加/3GB开关在Boot.ini文件。
（SQL会试图最大化的利用内存，你可以通过设置更改；最好给操作系统预留个几十M，方便应急情况下上去操作）
SQL Server: Buffer Manager: Buffer Cache Hit Ratio
描述：这个计数器相当重要，它说明了SQL Server 从缓冲区获取数据的命中率（如果缓冲区没有，只能去访问硬盘）。
范围：这个值应该在90%以上，理想情况是99%以上。当值比较低的时候，建议增加物理内存。
（即越高越好）
Physical Disk: Avg. Disk Queue Length
描述：这个计数器表明的是物理磁盘阵列的压力，即目前磁盘读取和写入请求队列的平均值。
范围：对单独的一个磁盘，如果其值大于2（如果是做了RAID的一组盘，假定有5个物理盘，则此判定值为2*5=10），且持续10分钟以上，则你可能碰到了磁盘I/O的瓶颈。因此这个值对单个磁盘应该 <=2。
（应用服务器也适用）
Physical Disk: % Disk Time
描述：这个计数器是判定物理磁盘阵列压力的指标。（不能针对一个逻辑分区或者阵列中的独立磁盘）
范围：如果这个值超过55%并持续10分钟以上，则数据库碰到了磁盘I/O瓶颈。因此这个值应该 <=55%。
（这是一个读/写的时间比值。读与写，事实上不同的厂家有不同的实现算法，所以相对于上一个计数器，这个指数我不常看，55%大家作个参考吧）
Processor: % Processor Time
描述：在数据库服务器上，每一个CPU都有此计数器的一个实例，它表明了独立CPU的利用率。
范围：如果总的% Processor Time (_Total) 超过80%且持续10分钟以上，就可能碰到了CPU的瓶颈。因此应该 <=80%。
（80%已经是严重问题了，到这个值以上服务器性能将急剧下降，应立即报警！个人认为60%就应重视起来，要去分析解决）
System: Processor Queue Length
描述：CPU处理任务队列中的任务个数。
范围：如果每个独立CPU，这个数值超过2，且持续10分钟以上，就可能碰到了CPU的瓶颈。因此对于每个独立CPU应该 <=2。
（应用服务器也适用）
----- ----- ----- ----- ----- ----- ----- -----
再附一个sql server的性能计数器，需要专业知识，有兴趣上官网，呵呵
除性能计数器外，SQL还有一些自带的监视、分析工具，这里篇幅有限不多写了，大家可以自己google一下（抓紧时间用吧）。主要的有：
² 管理sp、动态管理视图（SQL2005，很不错，推荐）
² SMS中的报表（傻瓜工具）
² 活动监视器
² profile（探查器？比较消耗资源，建议重要的生产库不要多用）
最后老生常谈一下：应用层、中间层的实现方式至关重要，到数据库层再来优化的就很有限了
