64位windows2003服务器版 *** 作系统任务计划运行的程序只是以进程形式运行??急急急啊!!

64位windows2003服务器版 *** 作系统任务计划运行的程序只是以进程形式运行??急急急啊!!,第1张

默认就是这样的,如果要可见可以用at命令的/interactive选项,计划任务的功能和at差不多,本身都是调用同一个服务的。
不过/interactive可能会导致严重的安全问题

通过WINDOWS自带的计划任务来实现: *** 作步骤:
1、打开“开始”/程序/附件/系统工具中”任务计划”,d出任务计划窗口;
2、然后双击”添加任务计划”;
3、运行“任务计划向导”,按“浏览”;
4、找到c盘下WINDOWS/SYSTEM32目录中的shutdownexe文件,单击”打开”按钮;
5、在出现的对话框中键入该任务的名字(如”reboot”),
执行方式选择“每周”

然后按“下一步”选择定时关机时间(可以先试一下比现在机器上显示的时间晚1分钟);
6、下一步选中“当单击完成打开该任务的高级属性”,单击”完成”。
另外也可以通过批处理来实现:
先要想让这计划任务起作用要在控制面板-》任务计划-》菜单(高级)-》开始任务计划程序
在开始-》运行里分别输入两条命令(也可以做成批处理文件,新建两个文本文档分别写入以下内容,保存为bat格式,双击即可)
at
24:00
/every:M,T,W,Th,F,S,Su
cmd
/c
shutdown
-r
-t
60(每天晚上12点自动重启一次)
at
6:00
/every:M,T,W,Th,F,S,Su
cmd
/c
shutdown
-r
-t
60
(每天早上6点自动重启一次)

在开始演示之前,我们先介绍下两个概念。

概念一,数据的可选择性基数,也就是常说的cardinality值。

查询优化器在生成各种执行计划之前,得先从统计信息中取得相关数据,这样才能估算每步 *** 作所涉及到的记录数,而这个相关数据就是cardinality。简单来说,就是每个值在每个字段中的唯一值分布状态。

比如表t1有100行记录,其中一列为f1。f1中唯一值的个数可以是100个,也可以是1个,当然也可以是1到100之间的任何一个数字。这里唯一值越的多少,就是这个列的可选择基数。

那看到这里我们就明白了,为什么要在基数高的字段上建立索引,而基数低的的字段建立索引反而没有全表扫描来的快。当然这个只是一方面,至于更深入的探讨就不在我这篇探讨的范围了。

概念二,关于HINT的使用。

这里我来说下HINT是什么,在什么时候用。

HINT简单来说就是在某些特定的场景下人工协助MySQL优化器的工作,使她生成最优的执行计划。一般来说,优化器的执行计划都是最优化的,不过在某些特定场景下,执行计划可能不是最优化。

比如:表t1经过大量的频繁更新 *** 作,(UPDATE,DELETE,INSERT),cardinality已经很不准确了,这时候刚好执行了一条SQL,那么有可能这条SQL的执行计划就不是最优的。为什么说有可能呢?

来看下具体演示

譬如,以下两条SQL,

A:

select from t1 where f1 = 20;

B:

select from t1 where f1 = 30;

如果f1的值刚好频繁更新的值为30,并且没有达到MySQL自动更新cardinality值的临界值或者说用户设置了手动更新又或者用户减少了sample page等等,那么对这两条语句来说,可能不准确的就是B了。

这里顺带说下,MySQL提供了自动更新和手动更新表cardinality值的方法,因篇幅有限,需要的可以查阅手册。

那回到正题上,MySQL 80 带来了几个HINT,我今天就举个index_merge的例子。

示例表结构:

mysql> desc t1;+------------+--------------+------+-----+---------+----------------+| Field      | Type         | Null | Key | Default | Extra          |+------------+--------------+------+-----+---------+----------------+| id         | int(11)      | NO   | PRI | NULL    | auto_increment || rank1      | int(11)      | YES  | MUL | NULL    |                || rank2      | int(11)      | YES  | MUL | NULL    |                || log_time   | datetime     | YES  | MUL | NULL    |                || prefix_uid | varchar(100) | YES  |     | NULL    |                || desc1      | text         | YES  |     | NULL    |                || rank3      | int(11)      | YES  | MUL | NULL    |                |+------------+--------------+------+-----+---------+----------------+7 rows in set (000 sec)

表记录数:

mysql> select count() from t1;+----------+| count() |+----------+|    32768 |+----------+1 row in set (001 sec)

这里我们两条经典的SQL:

SQL C:

select from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;

SQL D:

select from t1 where rank1 =100  and rank2 =100  and rank3 =100;

表t1实际上在rank1,rank2,rank3三列上分别有一个二级索引。

那我们来看SQL C的查询计划。

显然,没有用到任何索引,扫描的行数为32034,cost为324365。

mysql> explain  format=json select from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "324365"    },    "table": {      "table_name": "t1",      "access_type": "ALL",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "rows_examined_per_scan": 32034,      "rows_produced_per_join": 115,      "filtered": "036",      "cost_info": {        "read_cost": "323207",        "eval_cost": "1158",        "prefix_cost": "324365",        "data_read_per_join": "49K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))"    }  }}1 row in set, 1 warning (000 sec)

我们加上hint给相同的查询,再次看看查询计划。

这个时候用到了index_merge,union了三个列。扫描的行数为1103,cost为44109,明显比之前的快了好几倍。

mysql> explain  format=json select /+ index_merge(t1) / from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "44109"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "union(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1103,      "rows_produced_per_join": 1103,      "filtered": "10000",      "cost_info": {        "read_cost": "33079",        "eval_cost": "11030",        "prefix_cost": "44109",        "data_read_per_join": "473K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))"    }  }}1 row in set, 1 warning (000 sec)

我们再看下SQL D的计划:

不加HINT,

mysql> explain format=json select from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "53434"    },    "table": {      "table_name": "t1",      "access_type": "ref",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "idx_rank1",      "used_key_parts": [        "rank1"      ],      "key_length": "5",      "ref": [        "const"      ],      "rows_examined_per_scan": 555,      "rows_produced_per_join": 0,      "filtered": "007",      "cost_info": {        "read_cost": "47884",        "eval_cost": "004",        "prefix_cost": "53434",        "data_read_per_join": "176"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100))"    }  }}1 row in set, 1 warning (000 sec)

加了HINT,

mysql> explain format=json select /+ index_merge(t1)/ from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "523"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "intersect(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1,      "rows_produced_per_join": 1,      "filtered": "10000",      "cost_info": {        "read_cost": "513",        "eval_cost": "010",        "prefix_cost": "523",        "data_read_per_join": "440"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100) and (`ytt``t1``rank1` = 100))"    }  }}1 row in set, 1 warning (000 sec)

对比下以上两个,加了HINT的比不加HINT的cost小了100倍。

总结下,就是说表的cardinality值影响这张的查询计划,如果这个值没有正常更新的话,就需要手工加HINT了。相信MySQL未来的版本会带来更多的HINT。

针对每一个问答都本着绝不大胆胡说,只管小心求证的态度,疯评科技来解答您的提问。

想要随时随地监测服务器的运行情况,需要使用专业的监控软件。下面具体来说一说。

监控软件的功能要求

首先理清楚自己的需求,需要监控什么指标,监控方式,能否预警,历史数据是否保存,是否需要图形,只有对这些进行了充分了解,才能进行目标选定。

常用监控指标如下:

设备的运行状态有cpu使用情况,内存使用情况,硬盘使用情况,设备温度,运行时间等。

网络运行状态有流量,网卡状态,端口状态,路由条目数,路由协议状态等。

其它有ups运行状态,电量,光纤功率,电源状态等。

监控方式有snmp,,wmi,agent等。

预警需求有短信,电话,邮件,微信等。

相信经过这一系列的了解,对监控软件就走了选型了,这里我自己管理的网络用的流量监控软件是cacti和zabbix,其它状态监控用的是PRTG,还有设备厂商自带的监控软件。

监控软件的安装部署

在选定了监控软件后就是进行安装部署了,选用本地服务器还是云服务器都是可以的,需要服务器保持稳定,能够存储一定量的监控数据。

有的监控软件安装比较简单,比如Windows环境下的,涉及到数据库安装的就复杂一些,相比较而言,Linux下的监控软件性能更好,更稳定,当然非专业人员部署起来也比较困难。

监控软件安装完成后,需要进行必要的配置,包括监控目标的添加,参数调整,阈值设置,预警方式等。

在设置完整后,需要对所有配置保存并备份,并做定期备份计划,以确保数据安全。

随时随监测服务器

经过前面的准备,我们已经可以实现随时随地监测服务器了。具体实施可以如下来做:

有web登录功能的监控软件直接在手机浏览器中访问,并存入收藏夹,以被随时登录查看服务器状态。

有app客户端的监控软件则直接在手机上安装app进行查看。

没有web和app登录方式的则手机需要有远程软件,进行远程登录查看。

通过上述所说,用手机即可以轻松实现随时随地监测服务器的情况,当然有条件的,可以对监控软件进行二次开发或者自己开发所需功能的监控软件。

经典的启动“启动”文件夹,单击“开始→程序”,“启动”菜单,这就是最经典的Windows启动位置,放在这合理的程序和快捷方式都会在系统启动时自动运行。

智能的启动——开/关机/登录/注销脚本:
在Windows中,单击“开始→运行”,输入gpeditmsc回车可以打开“组策略编辑器”,在左侧窗格展开“本地计算机策略→ 用户配置→管理模板→系统→登录”,然后在右窗格中双击“在用户登录时运行这些程序”,单击“显示”按钮,在“登录时运行的项目”下就可以添加自启动的程序。

定时的启动——任务计划:
在默认情况下,“任务计划”程序随Windows一起启动并在后台运行。如果把某个程序添加到计划任务文件夹,并将计划任务设置为“系统启动时”或 “登录时”,这样也可以实现程序自启动。通过“计划任务”加载的程序一般会在任务栏系统托盘区里有它们的图标。可以双击“控制面板”中的“计划任务”图标查看其中的项目。

注册表启动项:注册表是启动程序最多的地方,主要有以下几项:
1Run键
Run键是病毒最青睐的自启动之所,该键位置是[HKEY_CURRENT_
USER\Software\Microsoft\Windows\CurrentVersion\Run]和[HKEY_
LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run],其下的所有程序在每次启动登录时都会按顺序自动执行。
还有一个不被注意的Run键,位于注册表[HKEY_CURRENT_
USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run]和 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\
Policies\Explorer\Run]。
2RunOnce键
RunOnce位于[HKEY_CURRENT_USER\Software\Microsoft\Windows\
CurrentVersion\RunOnce]和[HKEY_LOCAL_MACHINE\Software\Microsoft\
Windows\CurrentVersion\RunOnce]键,与Run不同的是,RunOnce下的程序仅会被自动执行一次。
3RunServicesOnce键
RunServicesOnce键位于[HKEY_CURRENT_USER\Software\Microsoft\
Windows\CurrentVersion\RunServicesOnce]和[HKEY_LOCAL_MACHINE\
Software\Microsoft\Windows\CurrentVersion\RunServicesOnce]下,其中的程序会在系统加载时自动启动执行一次。
4RunServices键
RunServices继RunServicesOnce之后启动的程序,位于注册表[HKEY_CURRENT_USER\Software \Microsoft\Windows\CurrentVersion\RunServices]和[HKEY_LOCAL_MACHINE \SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices]键。

5RunOnceEx键
该键是WindowsXP/2003特有的自启动注册表项,位于[HKEY_
CURRENT_USER\\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx]和 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx]。

6load键
[HKEY_CURRENT_USER\Software\Microsoft\WindowsNT\CurrentVersion\Windows]下的load键值的程序也可以自启动。
7Winlogon键
该键位于位于注册表[HKEY_CURRENT_USER\SOFTWARE\
Microsoft\WindowsNT\CurrentVersion\Winlogon]和[HKEY_LOCAL_MACHINE\
SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon],注意下面的Notify、Userinit、Shell键值也会自启动程序,而且其键值可以用逗号分隔,从而实现登录的时候启动多个程序。

8其他注册表位置
还有一些其他键值,经常会有一些程序在这里自动运行,如:[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System\Shell]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellServiceObjectDelayLoad]
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System\Scripts]
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\Scripts]

提示:注册表的[HKEY_LOCAL_MACHINE]和[HKEY_CURRENT_USER]键的区别:前者对所有用户有效,后者只对当前用户有效。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/13484103.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-08-16
下一篇 2023-08-16

发表评论

登录后才能评论

评论列表(0条)

保存