随着Sybase被完全整合到SAP下，Sybase原来的支持网站被SAP Support Portal取代。
只有购买了SAP服务的用户才能使用账号登录SAP Support Portal进行介质下载、补丁升级、报Incident等。
目前，原Sybase所有产品（包括：Adaptive Server Enterprise、Sybase IQ、Replication Server、PowerDesigner等）的官方手册仍然可以从https://infocenter.sybase.com/help/index.jsp进行浏览或下载。暂不清楚该网站https://infocenter.sybase.com/help/index.jsp何时会被完全迁移到SAP Support上！
Sybase官方手册英文版有html和pdf两种格式，而中文版手册只有pdf一种格式。为了国内Sybase用户更方便、快捷地搜索Sybase常见产品的官方手册内容，特将中文版Sybase官方手册转为html格式！
Sybase产品官方手册中文版的html格式所有内容的版权归SAP公司所有！本博客站长是Sybase数据库的铁杆粉丝！
如有Sybase数据库技术问题需要咨询，请联系我！
以下官方手册为ASE 15.7 ESD#2中文版：
- 新增功能公告 适用于 Windows、Linux 和 UNIX 的 Open Server 15.7 和 SDK 15.7
- 新增功能摘要
- 新增功能指南
- ASE 15.7 发行公告
- 配置指南（windows）
- 安装指南（windows）
- 参考手册：构件块
- 参考手册：命令
- 参考手册：过程
- 参考手册：表
- Transact-SQL® 用户指南
- 系统管理指南，卷 1
- 系统管理指南，卷 2
- 性能和调优系列：基础知识
- 性能和调优系列：锁定和并发控制
- 性能和调优系列：监控表
- 性能和调优系列：物理数据库调优
- 性能和调优系列：查询处理和抽象计划
- 性能和调优系列：使用 sp_sysmon 监控 Adaptive Server
- 性能和调优系列：利用统计分析改进性能
- 程序员参考 jConnect for JDBC 7.0.7
- Adaptive Server Enterprise 中的 Java
- 组件集成服务用户指南
- Ribo 用户指南
- 内存数据库用户指南
- Sybase Control Center for Adaptive Server® Enterprise
- 安全性管理指南
- 实用程序指南
注释 “Kernel Utilization”部分报告的信息取决于您运行 Adaptive Server 时采用的模式：线程模式或进程模式 （对于进程模式，请参见 第 29 页 的 “内核利用率 — 进程模式 ”）。
报告 Adaptive Server 活动。它将报告 CPU 可供 Adaptive Server 使用时 Adaptive Server 引擎的繁忙程度、 CPU 将控制权交给操作系统的频率、 引擎检查网络和磁盘 I/O 的次数以及每次检查时所找到的处于等待状态 的引擎的平均 I/O 数。
样本输出
内核使用率
下面的样本显示了有一个线程池 syb_default_pool 和三个 Adaptive Server
引擎的环境中 “内核利用率”的 sp_sysmon 输出。
------------------
Engine Utilization (Tick %) User Busy System Busy I/O Busy Idle
----------------------- ------------ ------------ ---------- --------
ThreadPool :syb_default_pool
Engine 0 8.7 % 0.8 % 31.1 % 59.5 %
Engine 1 8.0 % 0.1 % 33.2 % 58.7 %
Engine 2 8.8 % 0.3 % 32.7 % 58.2 %
Engine 3 15.0 % 0.3 % 32.6 % 52.0 %
------------------------- ------------ ------------ ---------- -------
Server Summary Total 40.4 % 1.6 % 129.6 % 228.4 %
Average 10.1 % 0.4 % 32.4 % 57.1 %
Average Runnable Tasks 1 min 5 min 15 min % of total
------------------------- ---------- ---------- ------- --------
ThreadPool :syb_default_pool
Global Queue 0.0 0.0 0.0 0.0 %
Engine 0 0.3 0.2 0.1 61.7 %
Engine 1 0.0 0.0 0.0 0.7 %
Engine 2 0.1 0.1 0.0 17.3 %
------------------------- ------------ ------------ ---------
Pool Summary Total 0.5 0.3 0.1
Average 0.1 0.1 0.0
------------------------- ------------ ------------ ---------
Server Summary Total 0.5 0.3 0.1
Average 0.1 0.1 0.0
CPU Yields by Engine per sec per xact count % of total
------------------------- -------- ---------- -------- --------
|
Full Sleeps |
20.4 |
13.8 |
2442 |
4.2 |
% |
|
|
Interrupted |
Sleeps |
81.7 |
55.4 |
9800 |
16.7 |
% |
|
Full Sleeps |
20.4 |
13.8 |
2442 |
4.2 |
% |
|
|
Interrupted |
Sleeps |
81.7 |
55.4 |
9800 |
16.7 |
% |
ThreadPool :syb_default_pool Engine 0
|
Full Sleeps |
22.8 |
15.5 |
2740 |
4.7 |
% |
|
|
Interrupted |
Sleeps |
89.1 |
60.4 |
10697 |
18.3 |
% |
|
Full Sleeps |
22.8 |
15.5 |
2740 |
4.7 |
% |
|
|
Interrupted |
Sleeps |
89.1 |
60.4 |
10697 |
18.3 |
% |
Engine 1
|
Full Sleeps |
19.9 |
13.5 |
2390 |
4.1 |
% |
|
|
Interrupted |
Sleeps |
93.4 |
63.3 |
11202 |
19.1 |
% |
|
Full Sleeps |
19.9 |
13.5 |
2390 |
4.1 |
% |
|
|
Interrupted |
Sleeps |
93.4 |
63.3 |
11202 |
19.1 |
% |
Engine 2
Engine 3
|
Full Sleeps |
17.8 |
12.1 |
2133 |
3.6 |
% |
|
|
Interrupted |
Sleeps |
142.6 |
96.7 |
17113 |
29.2 |
% |
|
------------------------- |
------------ |
------------ ---------- |
||||
|
Pool Summary |
487.6 |
330.6 58517 |
||||
|
------------------------- |
------------ |
------------ |
|
Total CPU Yields |
487.6 |
330.6 |
|
------------------------- |
------------ |
------------ |
|
Total CPU Yields |
487.6 |
330.6 |
----------
58517
Thread Utilization (OS %) User Busy System Busy Idle
------------------------- ------------ ------------ ----------
|
Thread |
6 |
(Engine |
0) |
0.0 |
% |
0.0 |
% |
100.0 |
% |
|
Thread |
7 |
(Engine |
1) |
0.2 |
% |
0.0 |
% |
99.8 |
% |
|
Thread |
8 |
(Engine |
2) |
0.0 |
% |
0.0 |
% |
100.0 |
% |
|
------------------------- ------------ ------------ ---------- |
|||||||||
|
Pool Summary |
Total |
0.2 |
% |
0.0 |
% |
299.9 |
% |
||
|
Average |
0.1 |
% |
0.0 |
% |
99.9 |
% |
|||
|
Thread |
6 |
(Engine |
0) |
0.0 |
% |
0.0 |
% |
100.0 |
% |
|
Thread |
7 |
(Engine |
1) |
0.2 |
% |
0.0 |
% |
99.8 |
% |
|
Thread |
8 |
(Engine |
2) |
0.0 |
% |
0.0 |
% |
100.0 |
% |
|
------------------------- ------------ ------------ ---------- |
|||||||||
|
Pool Summary |
Total |
0.2 |
% |
0.0 |
% |
299.9 |
% |
||
|
Average |
0.1 |
% |
0.0 |
% |
99.9 |
% |
|||
ThreadPool :syb_blocking_pool :no activity during sample ThreadPool :syb_default_pool
ThreadPool :syb_system_pool
|
Thread 10 (NetController) |
0.1 % |
0.0 % |
99.9 % |
|
------------------------- |
------------ |
------------ |
---------- |
|
Pool Summary Total |
1.1 % |
0.0 % |
400.0 % |
|
Average |
0.0 % |
0.0 % |
100.0 % |
------------------------- ------------ ------------ ----------
|
Server Summary |
Total |
0.2 % |
0.0 % |
1099.8 % |
|
Average |
0.0 % |
0.0 % |
100.0 % |
Adaptive Server threads are consuming 0.0 CPU units. Throughput (committed xacts per CPU unit) :275.0
Page Faults at OS per sec per xact count % of total
|
------------------------- Minor Faults |
-------- 0.6 |
---------- 0.4 |
-------- 69 |
-------- 100.0 % |
|
Major Faults |
0.0 |
0.0 |
0 |
0.0 % |
|
------------------------- Total Page Faults |
-------- 0.6 |
---------- 0.4 |
-------- -------- 69 100.0 % |
|
|
Context Switches at OS ------------------------- |
per sec -------- |
per xact ---------- |
count % of total -------- -------- |
|
|
ThreadPool :syb_blocking_pool |
||||
|
Voluntary |
0.0 |
0.0 |
0 |
0.0 % |
|
Non-Voluntary |
0.0 |
0.0 |
0 |
0.0 % |
|
ThreadPool :syb_default_pool |
||||
|
Voluntary |
43.6 |
130.7 |
1307 |
56.3 % |
|
Non-Voluntary |
0.2 |
0.6 |
6 |
0.3 % |
|
ThreadPool :syb_system_poo Voluntary |
l 33.7 |
101.0 |
1010 |
43.5 % |
|
Non-Voluntary ------------------------- Total Context Switches |
0.0 ----------- 77.4 |
0.0 ------------ 232.3 |
0 ---------- 2323 |
0.0 % --------- 100.0 % |
|
CtlibController Activity |
per sec |
per xact |
count |
% of total |
|
------------------------- |
-------- |
---------- |
-------- |
-------- |
|
Polls |
1.0 |
0.7 |
120 |
n/a |
|
Polls Returning Events |
0.0 |
0.0 |
0 |
0.0 % |
|
DiskController Activity |
per sec |
per xact |
count |
% of total |
|
------------------------- |
-------- |
---------- |
-------- |
-------- |
|
Polls |
35019.1 |
23741.8 |
4202292 |
n/a |
|
Polls Returning Events |
351.2 |
238.1 |
42145 |
1.0 % |
|
Polls Returning Max Events |
0.0 |
0.0 |
0 |
0.0 % |
|
Total Events |
374.9 |
254.1 |
44984 |
n/a |
|
Events Per Poll |
n/a |
n/a |
0.011 |
n/a |
|
etController Activity ------------------------- |
per sec |
per xact |
count |
% of total |
|
|
-------- |
---------- |
-------- |
-------- |
||
|
Polls |
7919.5 |
5369.1 |
950338 |
n/a |
|
|
Polls |
Returning Events |
2537.8 |
1720.5 |
304536 |
32.0 % |
|
Polls |
Returning Max Events |
0.0 |
0.0 |
0 |
0.0 % |
|
Total |
Events |
2537.8 |
1720.5 |
304536 |
n/a |
|
etController Activity ------------------------- |
per sec |
per xact |
count |
% of total |
|
|
-------- |
---------- |
-------- |
-------- |
||
|
Polls |
7919.5 |
5369.1 |
950338 |
n/a |
|
|
Polls |
Returning Events |
2537.8 |
1720.5 |
304536 |
32.0 % |
|
Polls |
Returning Max Events |
0.0 |
0.0 |
0 |
0.0 % |
|
Total |
Events |
2537.8 |
1720.5 |
304536 |
n/a |
N
Events Per Poll n/a n/a 0.320 n/a
|
Blocking Call Activity |
per sec |
per xact |
count |
% of total |
|
------------------------- |
-------- |
---------- |
-------- |
-------- |
|
Total Requests |
0.0 |
0.0 |
0 |
n/a |
Engine Utilization (Tick %)
使用内部测量方式 （“时钟周期”）报告 Adaptive Server 内核在每个 Adaptive Server 引擎上忙于执行任务的时间 （而非空闲时间）的百分比。 输出根据线程池分组。“Server Summary”显示所有池的总时间。
“ Engine Utilization (Tick %)”可帮助确定 Adaptive Server 引擎是过多还 是过少。
“ Engine Utilization (Tick %)”报告中显示的值可能与操作系统工具所报 告的 CPU 使用率值不同。当 Adaptive Server 没有要处理的任务时，它将 进入循环，在休眠之前查找工作。alter thread pool ... idle timeout 参数控制 Adaptive Server 引擎在放弃 CPU 之前查找可运行任务时在循环中花费的 时间长度 （以毫秒为单位）。
若要缩短 Adaptive Server 检查可运行任务所花费的时间，请减小 idle timeout 线程池参数的值。不过，减小 idle timeout 的值可能会增加延迟， 从而降低性能。
当 sp_sysmon 对计数器进行采样时 （缺省情况下，每 100 毫秒采样一 次），每个引擎均指示当前正在执行的操作。 sp_sysmon 报告引擎的繁忙 程度，以区分用户任务和系统任务：
• “User Busy”— 用户任务，例如用户连接。
• “System Busy”— 内部任务，例如管家。
例如，如果执行某项任务，引擎将报告 "CPU Busy"；如果空闲，引擎将 报告 "Idle"。如果 Adaptive Server 有任何未完成的 I/O 而引擎处于空闲 状态，则引擎将被视为 "I/O Busy"。如果有一个未完成的 I/O 和三个处 于空闲状态的引擎，则每个引擎都将被视为 "I/O Busy"。
通过检查 sp_sysmon 输出中的问题以及进行调优以缓解争用，即使引擎 报告的繁忙时间在 80-90% 范围内，响应时间仍旧非常快。如果此值一 直很高 （大于 90%），则增加引擎可能会缩短响应时间和提高吞吐量。
“Engine Utilization (Tick %)”值是采样间隔期间的平均值，因此，如果平 均值非常高，则表明该引擎在采样间隔的部分时间内可能处于 100% 繁 忙状态。如果服务器的 CPU 使用率很高，请检查是否存在螺旋锁争用。 内存表扫描也会增加 CPU 使用率，您可以通过相应地调整查询来降低 CPU 使用率。
当引擎利用率极其高时， housekeeper 清洗任务只将很少的页或不将任何 页写入磁盘中 （因为它仅在 CPU 空闲周期内运行）。这意味着检查点可 找到许多需要写入磁盘的页，而且检查点进程、大型批处理作业或数据 库转储可能会在一段时间内将 CPU 使用率提高到 100%，从而导致响应 时间的明显增加。
如果 “ Engine Utilization (Tick %)”百分比一直很高，而且您要通过添加 Adaptive Server 引擎缩短响应时间并增加吞吐量，则可在添加每个引擎 后检查其它方面的资源争用是否增加。
在一个Adaptive Server为许多用户提供服务的环境中，性能通常会在各引 擎间相当均匀地分布。然而，当引擎数大于任务数时，则可能会使某些 引擎利用率百分比很高，而其它引擎却可能会空闲。
例如：
|
Engine Utilization (Tick %) |
User Busy |
System Busy |
I/O Busy |
Idle |
|
------------------------- |
------------ |
------------ |
---------- |
------- |
|
ThreadPool :Marketing_pool |
||||
|
Engine 3 |
78.0 % |
4.5 % |
3.4 % |
18.0 % |
ThreadPool :syb_default_pool
|
Engine |
0 |
8.7 |
% |
.8 |
% |
1.3 |
% |
94.8 |
% |
|
Engine |
1 |
87.0 |
% |
5.2 |
% |
3.5 |
% |
19.4 |
% |
|
Engine |
2 |
65.7 |
% |
3.7 |
% |
3.7 |
% |
12.8 |
% |
在 SMP 环境下，任务与引擎间具有软性密切连接。如果不存在可能会将 任务放置在全局运行队列中的其它活动 （如锁争用），则此任务会继续 在同一引擎上运行。
Average Runnable Tasks
使用 monSysLoad 监控表中的可运行任务平均值来提供 1 分钟、5 分钟和 15 分钟内的可运行任务平均值。引擎上所有正在运行 （和可运行）的任 务都包含在该平均值中。分钟间隔是固定的，不会随着您配置的 sp_sysmon 采样时间变化。
通过可运行任务数，可以很好地衡量 Adaptive Server 的繁忙程度。例如， 与平均 “Engine Utilization”为 90% 且可运行任务数很低的服务器相比， 平均 “Engine Utilization”为 90% 且可运行任务数很高的服务器更有可 能从额外的引擎中获益。
比较 1 分钟、5 分钟和 15 分钟内的采样可帮助您确定服务器上的负载是 在增加、保持稳定还是在减少。
报告每个 Adaptive Server 引擎将控制权交给操作系统的次数。在引擎交 出控制权后，它将进入休眠状态并持续短暂的一段时间。如果在唤醒后 发现没有可运行的任务，它会再次进入休眠状态。输出内容根据线程池 以及与线程池关联的引擎排列。对于每个引擎， sp_sysmon 都报告以下 内容：
• Full Sleeps — 引擎在其完全休眠间隔内保持休眠状态 （即，在休眠 时未接收可运行任务）。完全休眠很可能导致另一次休眠。不过，完 全休眠不会增加延迟。
• Interrupted Sleeps — 引擎被可运行任务从休眠状态提前唤醒。中断式 休眠很可能导致预定任务。中断式休眠可能会增加延迟。
“% of total”数据是一个引擎的放弃次数占所有引擎的组合放弃次数的百 分比。
“ Total CPU Yields”报告基于所有引擎的组合数据。 当引擎不忙时，它会在与 idle timeout 参数有关的一段时间后放弃 CPU。
• Engine Utilization 低/CPU Yields 低 — I/O Busy% 列的值大于 CPU Busy% 列的值表示存在大量未完成的 I/O。若要解决 I/O 处理过程中的瓶颈， 请查看您可以在操作系统级别进行的更改。
• Engine Utilization 低/CPU Yields 高 — 引擎处于不活动状态。
• Engine Utilization 高/CPU Yields 低 — Adaptive Server 非常繁忙，并 且有作业需要运行。添加引擎可能有助于提高性能。该值还应该与 较高的 “Average Runnable Tasks”值相关。
• Engine Utilization 高/CPU Yields 高 — 这应该是有正常数量的用户连 接在运行简单查询时出现的情况。添加引擎可能没有帮助，除非 “Engine Utilization”非常高或 “Average Runnable Tasks”数很高。
• 大多数引擎放弃应该属于 “完全休眠”。如果 “中断式休眠”占引 擎总放弃数的 20% 以上，则总体延迟可能会增加。若要降低延迟， 可考虑增加 idle timeout 的值。不过，这会提高 CPU 使用率。
请参见 《参考手册：命令》中的 alter thread pool。
Thread Utilization (OS %)
显示每个 Adaptive Server 线程在操作系统级别花费的时间。这部分时间 是线程实际使用 CPU 的时间。“Pool Summary”表示在线程池中使用的 线程的百分比。“Server Summary”描述在 Adaptive Server 中使用的线程 的百分比。
“User time”报告在 sp_sysmon 采样间隔期间内线程在用户空间内执行代 码 （即，在 Adaptive Server 中运行）的时间百分比。“System time”报 告在 sp_sysmon 采样间隔期间内线程在系统空间内执行代码 （即，在操 作系统内核中运行）的时间百分比。这种区别与 “Engine Utilization (Tick %)”部分中报告的 “User Busy”和 “System Busy”无关。
注释 由于 Adaptive Server 收集数据的方式所致， sp_sysmon 可能会显 示某些线程的利用率超过 100%。
在检查 “Thread Utilization (OS%)”输出时，应考虑：
• “Thread Utilization (OS %)”值应高于 “Engine Utilization (Tick %)” 值。当 idle timeout 设置为较高的值，而负载不连续时，它们之间的 差异最大。例如，100% 空闲但 idle timeout 为 -1 的引擎显示 0% 的引 擎利用率但却显示 100% 的线程利用率。
• 大于 “Thread Utilization (OS %)”值的 “Engine Utilization (Tick %)” 值可能表示主机上的 CPU 资源不足。这通常表示引擎没有收到所需 的足够 CPU 时间，这可能导致性能严重下降。如果还涉及到螺旋锁 争用，则性能可能会严重下降。
• 磁盘或网络任务的高 “Thread Utilization (OS %)”值可能表示系统需 要一项额外的磁盘或网络任务。例如，如果网络任务线程的繁忙率为 80%，但引擎利用率很低，则达到饱和状态的网络任务很可能使引擎 无工作可做。使用 sp_configure "number of network tasks" 添加网络任务 可以减轻这种状况。
在 “Thread Utilization (OS %)”末尾，sp_sysmon 报告 Adaptive Server 线 程使用的 CPU 单元数以及每个 CPU 的提交事务的吞吐量。例如：
Adaptive Server threads are consuming 5.6 CPU units. Throughput is 8238.0 commited xacts per CPU unit.
可以将使用的 CPU 单元数与可供 Adaptive Server 使用的物理硬件进行比 较。例如，如果系统有 8 个内核，每个内核 2 个线程，则总共有 16 个可 用 CPU 单元。如果 Adaptive Server 使用了 6 个 CPU 单元，则主机就可 以执行其它工作。但是，如果 Adaptive Server 使用了 14 个 CPU 单元， 剩下的容量就非常少，子内核线程就会被过度使用。
Page Faults at OS
报告主要和次要页面错误数以及所有页面错误的摘要。仅当报告了页面 错误时， sp_sysmon 才会显示该部分。
注释 对于 Windows 系统，不会出现 “Page Faults at OS”。
• Minor Faults — 当 Adaptive Server 需要的内存页在内存管理单元中未 标记为可用但在物理内存中却可用时，会出现此错误。
• Major Faults — 当 Adaptive Server 需要的内存页在物理内存中不可用， 必须从磁盘检索该页时，会出现此错误。
次要和主要页面错误均表示物理内存可能不足。主要页面错误对性能的 影响远大于次要页面错误。主要页面错误表示对于主机而言，您将 Adaptive Server 内存配置设置得过高，或者其它进程 （如文件系统高速 缓存）正在使用 Adaptive Server 所需的物理页。
Context Switches at OS
报告 Adaptive Server 线程在操作系统级别执行的自愿和非自愿环境切换 数。仅当报告了环境切换，并且操作系统支持收集数据时， sp_sysmon 才 会显示该部分。
注释 对于 Windows、 Red Hat 5 或 SLES 11 系统，不会出现 “Page Faults at OS”。
Adaptive Server 可能出于多种原因执行 “自愿”环境切换，例如由于 I/O 轮询或引擎休眠。环境切换的数量取决于负载。当操作系统在 Adaptive Server 线程未请求删除的情况下从 CPU 中删除该线程时 （例如，当操作 系统抢占该线程时），即发生 “非自愿”环境切换。“非自愿”环境切换 可能表示主机的 CPU 资源不足，以及 Adaptive Server 性能可能受到严重 影响。出现少量非自愿环境切换是正常的，这并不表示存在问题。
下面的样本输出来自一个未过度配置的系统。“非自愿”环境切换数非 常低：
|
Context Switches at OS |
per sec |
per xact |
count |
% of total |
|
------------------------- |
----------- |
------------ |
--------- |
---------- |
|
Voluntary |
278.7 |
278.7 |
2787 |
99.7 % |
|
Non-Voluntary |
0.9 |
0.9 |
9 |
0.3 % |
|
------------------------- |
----------- |
------------ |
--------- |
---------- |
|
Total Context Switches |
279.6 |
279.6 |
2796 |
100.0 % |
下面的样本输出来自一台过载的计算机，“非自愿”环境切换级别非 常高：
|
Context Switches at OS |
per sec |
per xact |
count |
% of total |
|
------------------------- |
----------- |
------------ |
--------- |
---------- |
|
Voluntary |
2683.7 |
16370.4 |
163704 |
18.4 % |
|
Non-Voluntary |
11893.0 |
72547.4 |
725474 |
81.6 % |
|
------------------------- |
----------- |
------------ |
--------- |
---------- |
|
Total Context Switches |
14576.7 |
88917.8 |
889178 |
100.0 % |
为了改善这种情况，可减少引擎数，从主机中删除非 Adaptive Server 负 载，添加更多 CPU，或者迁移到具有更大处理能力的主机。
CtlibController Activity、 DiskController Activity 和 NetController Activity
“CtlibController Activity”描述 Adaptive Server 检查 Client Library ( CTLIB ) 控制器事件的频率（在 Polls 行中指示）以及 Client Library 返回事件的 次数 （在 Polls Returning Events 行中指示）。
“DiskController Activity”描述 Adaptive Server 检查磁盘控制器事件的频 率（在 Polls 行中指示）以及磁盘返回事件的次数（在 Polls Returning Events 行中指示）。
“NetController Activity”描述 Adaptive Server 检查网络控制器事件的频 率（在 Polls 行中指示）以及网络返回事件的次数（在 Polls Returning Events 行中指示）。
这些部分包含以下行：
• Polls — 此控制器轮询操作系统以了解完成情况的次数。
• Polls Returning Events — 此控制器轮询操作系统并至少收到一个事件 的次数。
• Polls Returning Max Events — 操作系统轮询返回最大事件数的次数。
• Total Events — 返回的 I/O 事件总数。
• Events Per Poll — 每个池中返回的平均事件数。
如果配置多个磁盘或网络任务，则显示的数据将是该控制器的所有任务 的集合。
在以下情况下，可考虑添加磁盘或网络任务：
• “Polls Returning Max Events”大于零。
• “Events per Poll”的值大于三。
但是，在添加其它磁盘或网络任务之前，应检查控制器的 “Thread Utilization”值和整体系统负载。
Blocking Call Activity
报告阻塞调用任务 （即，对 syb_blocking_pool 的请求）。如果存在很大 比例的排队请求或需要等待很长时间，可考虑调整 syb_blocking_pool 的 大小。
报告 Adaptive Server 活动。它将报告 CPU 可供 Adaptive Server 使用时 Adaptive Server 引擎的繁忙程度、 CPU 将控制权交给操作系统的频率、 引擎检查网络和磁盘 I/O 的次数以及每次检查时所找到的处于等待状态 的引擎的平均 I/O 数。
样本输出
Kernel Utilization
------------------
下面的样本显示了有八个 Adaptive Server 引擎的环境中 “内核利用率” 的 sp_sysmon 输出。
Your Runnable Process Search Count is set to 2000 and I/O Polling Process Count is set to 10
|
Engine Busy Utilization ------------------------ |
CPU Busy -------- |
I/O Busy -------- |
Idle -------- |
|||
|
Engine |
0 |
3.3 |
% |
13.7 |
% |
83.0 % |
|
Engine |
1 |
2.4 |
% |
9.2 |
% |
88.4 % |
|
Engine |
2 |
4.9 |
% |
19.9 |
% |
75.2 % |
|
Engine |
3 |
.8 |
% |
19.1 |
% |
76.1 % |
|
Engine |
4 |
2.8 |
% |
7.0 |
% |
90.2 % |
|
Engine |
5 |
1.9 |
% |
7.3 |
% |
90.8 % |
|
Engine |
6 |
2.5 |
% |
7.6 |
% |
89.9 % |
|
Engine |
7 |
2.0 |
% |
8.1 |
% |
89.9 % |
|
------------------------ -------- -------- -------- |
||||||
|
Summary |
Total |
24.6 % |
91.9 % |
683.5 % |
||
|
Average |
3.1 % |
11.5 % |
85.4 % |
|||
|
CPU Yields by Engine |
per sec |
per xact |
count |
% of total |
|
------------------------- |
----------- |
----------- |
--------- |
--------- |
|
Engine |
0 |
31.5 |
0.0 |
2802 |
11.6 |
% |
|
Engine |
1 |
38.1 |
0.0 |
3388 |
14.0 |
% |
|
Engine |
2 |
21.8 |
0.0 |
1936 |
8.0 |
% |
|
Engine |
3 |
30.2 |
0.0 |
2689 |
11.1 |
% |
|
Engine |
4 |
37.9 |
0.0 |
3372 |
13.9 |
% |
|
Engine |
5 |
38.4 |
0.0 |
3421 |
14.1 |
% |
|
Engine |
6 |
36.1 |
0.0 |
3217 |
13.3 |
% |
|
Engine 7 ------------------------- |
38.4 ---------- |
0.0 ----------- |
3420 -------- |
14.1 |
% |
|
|
Total CPU Yields |
272.4 |
0.2 |
24245 |
|||
|
Network Checks Non-Blocking |
434722.4 |
366.8 |
38690292 |
99.9 |
% |
|
|
Blocking ------------------------- Total Network I/O Checks |
272.4 ---------- 434994.8 |
0.2 ----------- 367.1 |
24247 -------- 38714539 |
0.1 |
% |
|
|
Avg Net I/Os per Check |
n/a |
n/a |
0.00003 |
n/a |
||
|
Disk I/O Checks Total Disk I/O Checks |
435855.6 |
367.8 |
38791149 |
n/a |
||
|
Checks Returning I/O |
125358.1 |
105.8 |
11156875 |
28.8 % |
||
|
Avg Disk I/Os Returned |
n/a |
n/a |
0.00313 |
n/a |
||
报告 Adaptive Server 内核在每个 Adaptive Server 引擎上忙于执行任务的 时间 （而非空闲时间）的百分比。摘要行给出所有组合引擎的总活动时 间和平均活动时间。
“Engine Busy Utilization”报告中显示的值可能与操作系统工具所报告的 CPU 使用率值不同。当 Adaptive Server 没有要处理的任务时，它将进入 循环，定期检查是否有网络 I/O、是否有已完成的磁盘 I/O 以及运行队列 中是否有任务。
无法在 Adaptive Server 中进行的测量是 Adaptive Server 控制 CPU 的时间 相对于操作系统使用 CPU 的时间这两者的百分比。操作系统向 Adaptive Server 提供 CPU 时间。 sp_sysmon 报告 Adaptive Server 如何使用操作系 统提供的时间。应始终将 sp_sysmon 与操作系统的监控工具结合使用以 获取这两个系统的读数。
若要缩短 Adaptive Server 在空闲时检查 I/O 所花费的时间，可以降低 sp_configure 参数 runnable process search count。该参数指定 Adaptive Server 引擎在交出 CPU 控制权之前其循环操作查找可运行任务的次数。不过， 减小 runnable process search count 的值可能会增加延迟，从而降低性能。
“ Engine Busy Utilization”衡量 Adaptive Server 引擎在给定 CPU 时间内的 繁忙程度。如果在 10 分钟采样间隔内，Adaptive Server 可以利用引擎的 时间为 80%，且 “Engine Busy Utilization”为 90%，则意味着 Adaptive Server 的繁忙时间为 7 分 12 秒，而空闲时间为 48 秒。
当 sp_sysmon 对计数器进行采样时 （缺省情况下，每 100 毫秒采样一 次），每个引擎均指示当前正在执行的操作。例如，如果正在执行任务， 它会报告 "CPU Busy"；如果处于空闲状态，它会报告 "Idle"；如果处于 空闲状态，并且至少有一个未完成的异步磁盘 IO，它会报告 "IO Busy"。
“Engine Busy Utilization”可帮助确定 Adaptive Server 引擎是过多还是过 少。 Adaptive Server 的高可伸缩性归功于可避免资源争用的调优机制。
通过检查 sp_sysmon 输出中的问题以及进行调优以缓解争用，即使 “Engine Busy”值在 80 - 90% 范围内，响应时间仍旧非常快。如果此值 一直很高 （大于 90%），则增加引擎可能会缩短响应时间和提高吞吐量。
“Engine Busy Utilization”值是采样间隔期间的平均值，因此，如果平均 值非常高，则表明该引擎在采样间隔的部分时间内可能处于 80% 繁忙的 状态。螺旋锁争用会增加 CPU 使用率，如果服务器的 CPU 使用率很高， 则应检查是否存在螺旋锁争用。内存表扫描也会增加 CPU 使用率，您可 以通过相应地调整查询来降低 CPU 使用率。
当引擎利用率极其高时， housekeeper 清洗任务将很少的页或不将任何页 写入磁盘中 （因为它仅在 CPU 空闲周期内运行）。这表明检查点可找到 许多需要写入磁盘的页，而且检查点进程、大型批处理作业或数据库转 储可能会在一段时间内将 CPU 使用率提高到 100%，从而导致响应时间 的明显增加。
如果 “Engine Busy Utilization”百分比一直很高，而且您要通过添加 Adaptive Server 引擎缩短响应时间并增加吞吐量，则可在添加每个引擎 后检查其它方面的资源争用是否增加。
在一个Adaptive Server为许多用户提供服务的环境中，性能通常会在各引 擎间相当均匀地分布。然而，当引擎数大于任务数时，则可能会使某些 引擎利用率百分比很高，而其它引擎却可能会空闲。例如：
|
Engine Busy Utilization |
CPU Busy |
I/O Busy |
Idle |
||||
|
------------------------ |
--------- |
------- |
-------- |
||||
|
Engine |
0 |
68.7 |
% |
2.5 |
% |
28.8 |
% |
|
Engine |
1 |
61.9 |
% |
3.3 |
% |
34.8 |
% |
|
Engine |
2 |
67.0 |
% |
2.4 |
% |
30.6 |
% |
|
Engine |
3 |
69.0 |
% |
3.8 |
% |
27.2 |
% |
|
Engine |
4 |
60.2 |
% |
2.7 |
% |
37.2 |
% |
|
Engine |
5 |
55.7 |
% |
3.2 |
% |
41.1 |
% |
|
Engine |
6 |
53.8 |
% |
3.2 |
% |
43.0 |
% |
----------------------- -------- -------- --------
|
Summary |
Total |
436.3 % |
21.1 % |
242.6 % |
|
Average |
62.3 % |
3.0 % |
34.7 % |
在 SMP 环境下，任务与引擎间具有软性密切连接。如果不存在可将任务 放置在全局运行队列中的其它活动 （如锁争用），则此任务会继续在同 一引擎上运行。
每个 Adaptive Server 引擎将控制权交给操作系统的次数。“% of total”数 据是一个引擎的放弃次数占所有引擎的组合放弃次数的百分比。
“Total CPU Yields”报告基于所有引擎的组合数据。但是，具有一个或 多个未完成异步磁盘 I/O 的引擎不会交出 CPU 控制权，即使 runnable process search count 已经用完。
如果 “ Engine Busy Utilization”数据表明引擎利用率低，请使用 “CPU Yields by Engine”确定 “Engine Busy Utilization”数据是否反映了真正 不活动的引擎或其 CPU 经常被操作系统夺走的引擎。
引擎不忙时，它会在与 runnable process search count 参数有关的一段时间 后放弃 CPU。“CPU Yields by Engine”的值较大时表明引擎主动放弃。
• Engine Busy 低/CPU Yields 低 — I/O Busy% 列的值高于 CPU Busy% 列的值表示存在大量未完成的 I/O。请查看您可以在操作系统级别进 行的更改，以解决 I/O 处理过程中的瓶颈。如果 Adaptive Server 系统 CPU 时间过高（基于操作系统输出），请减小 runnable process search count 的值。
• Engine Busy 低/CPU Yields 高 — 引擎处于不活动状态。
• Engine Busy 高/CPU Yields 低 — Adaptive Server 非常繁忙，并且有 作业需要运行。添加引擎可能有助于提高性能。
• Engine Busy 高/CPU Yields 低 — 这应该是有正常数量的用户连接运 行简单查询时出现的情况。降低 runnable process search count 可 能几乎没有什么效果。添加引擎也不太可能有帮助，除非 “Engine Busy Utilization”非常高。
请参见 《系统管理指南，卷 1》中的第 5 章 “设置配置参数”。
|
CPU Yields by Engine |
per sec |
per xact |
count |
% of total |
||
|
------------------------ |
------------ |
----------- |
-------- |
--------- |
||
|
Engine |
0 |
73.5 |
1.8 |
44087 |
26.2 |
% |
|
Engine |
1 |
40.4 |
1.0 |
24224 |
14.4 |
% |
|
Engine |
2 |
23.7 |
0.6 |
14208 |
8.4 |
% |
|
Engine |
3 |
36.2 |
0.9 |
21746 |
12.9 |
% |
|
Engine |
4 |
38.7 |
1.0 |
23207 |
13.8 |
% |
|
Engine 5 |
41.3 |
1.0 |
24760 |
14.7 % |
|
Engine 6 |
26.8 |
0.7 |
16108 |
9.6 % |
|
---------------------- |
------------ |
---------- |
-------- |
|
|
Total CPU Yields |
280.6 |
6.9 |
168340 |
Network Checks
Network Checks
报告以下相关信息：阻塞和非阻塞网络 I/O 检查、间隔期间进行的 I/O 检 查的总数以及每次网络检查的网络 I/O 的平均数。
Adaptive Server 具有两种检查网络 I/O 的方法：阻塞模式和非阻塞模式。
Non-Blocking 166371.5 4098.3 99822899 99.8 %
Blocking 279.0 6.9 167388 0.2 %
------------------------- --------- -------- ---------
Total Network I/O Checks 166650.5 4105.2 99990287
Avg Net I/Os per Check n/a n/a 0.00476 n/a
Adaptive Server 执行非阻塞网络检查的次数。通过非阻塞网络 I/O 检查， 引擎可检查网络 I/O 并继续进行处理，而无论是否发现 I/O 处于等待状 态 （这是引擎检查网络 I/O 的通常方式）。
Adaptive Server 执行阻塞网络检查的次数。这是引擎将 CPU 控制权交给 操作系统的方式，应等于放弃次数 （由于计时问题，这可能会有所不同）。
引擎完成队列中的所有可运行任务后，将会循环短暂的一段时间，以轮 询网络并检查下一客户端请求。如果在特定的循环次数 （由 sp_configure 参数 runnable process search count 确定）后，引擎没有找到可运行任务， 并且不存在未完成的异步磁盘 I/O，则引擎将执行阻塞网络 I/O 轮询，将 其 CPU 控制权交给操作系统。此时，引擎就称为进入休眠状态。
休眠引擎每个时钟周期唤醒一次以执行例行管家任务和检查可运行任务。 如果没有可运行任务，引擎再执行一次阻塞网络检查，然后重新进入休 眠状态。
如果某个不同的引擎完成了某个网络 I/O，Adaptive Server 可能会在下一 时钟周期之前唤醒休眠引擎。唤醒后，引擎将执行处理后 I/O 工作，这 通常会导致任务成为可运行任务 （在 I/O 工作处理完毕之前，该任务不 太可能再次交出 CPU 控制权）。
引擎对进入包和发出包的轮询次数。此类别与 “ CPU Yields by Engine” 结合使用时很有用处。
引擎处于空闲状态时，会进行循环，同时检查网络包。如果 “Network Checks”很低而 “CPU Yields by Engine”很高，则引擎可能过于频繁地 放弃 CPU 而不能以足够的频率检查网络。如果系统能够承受此开销，或 许可以接受减少放弃。
引擎循环您使用 runnable process search count 定义的次数后，才交出 CPU 控制权 （除非引擎至少有一个未完成的磁盘 I/O）。因此，引擎过于频繁 地交出 CPU 控制权可能表示因为 runnable process search count 设置得过 低而导致性能受到影响。
Average Network I/Os per Check
对于采样间隔期间进行的所有 Adaptive Server 引擎检查而言，每次检查 的网络 I/O （发送和接收）平均数。
sp_configure 参数 i/o polling process count 指定 Adaptive Server 在调度程序 检查磁盘和网络 I/O 是否完成之前运行的最大进程数。调整 i/o polling process count 既会影响响应时间，又会影响 Adaptive Server 的吞吐量。
有关配置参数的详细信息，请参见 《系统管理指南，卷 1》中的第 5 章 “设置配置参数”。
如果 Adaptive Server 引擎频繁进行检查，但不对网络 I/O 进行频繁检索， 则可以尝试降低网络 I/O 检查的频率。
磁盘 I/O 检查次数
磁盘 I/O 检查次数
报告磁盘 I/O 检查的总数，以及返回 I/O 的检查数量。
Total Disk I/O Checks 171839.7 4233.0 103103833 n/a
Checks Returning I/O 31783.1 782.9 19069887 18.5 % Avg Disk I/Os Returned n/a n/a 0.01722 n/a
• Checks Returning I/O — 实际检查次数。
• Avg Disk I/Os Returned — 产生一个或多个完成的 I/O 的 Checks Returning I/O 的百分比。
Total Disk I/O Checks
引擎进入例程以检查是否存在磁盘 I/O 的次数。io polling process count 配 置参数控制此项检查的频率。
当某个任务需要执行 I/O 时，运行该任务的 Adaptive Server 引擎立即发 出 I/O 请求并使任务休眠以等待 I/O 结束。此引擎可以处理其它任务，但 继续检查已完成的 I/O。引擎发现已完成的 I/O，会将此任务从休眠队列 移动到运行队列中。
在进入磁盘检查例程时 I/O 未完成的次数。 如果在服务器的一个时钟周期内或者在 "idle loops" 期间已经运行了
"io polling process count" 值所指定的任务数，则 Adaptive Server
引擎会轮询网络 I/O。但是，除非存在至少一个未完成的磁盘 IO，否则 引擎不会轮询磁盘 IO。 "Checks Returning IO" 表示引擎试图检查磁 盘 IO 的次数以及 Adaptive Server 试图检查并且至少存在一个未完成磁盘 IO 的次数。
例如，如果引擎检查预期的 I/O 100,000 次，则该平均值表示 I/O 实际挂 起时间的百分比。在这 100,000 次检查中，如果 I/O 完成 10,000 次，则检 查的 10% 有效，而另外 90% 为开销。
但是，仍应核对每次检查所返回的 I/O 平均数，以及采样间隔期间引擎的 繁忙程度。如果采样包括空闲时间，或者 I/O 通信量时有时无，则繁忙期 间可能会有很大比例的检查返回 I/O。
如果此类别的结果似乎较低或较高，则可配置 i/o polling process count 来增 加或降低检查的频率。
有关配置参数的详细信息，请参见 《系统管理指南，卷 1》中的第 5 章 “设置配置参数”。
产生一个或多个完成的 I/O 的 “Checks Returning I/O”的百分比。
增加两次检查之间 Adaptive Server 引擎的等待时间可带来更理想的吞吐 量，因为如果 Adaptive Server 引擎用较少的时间检查 I/O，就有更多的时 间来进行处理。但是，这需要在所使用的环境中加以证实。如果 I/O Busy% 值很高，则 Adaptive Server 应该更频繁地执行检查，以便在 I/O 完成后立 即选取它们。i/o polling process count 配置参数控制 Adaptive Server 执行此 项检查的频率。
有关配置参数的详细信息，请参见 《系统管理指南，卷 1》中的第 5 章 “设置配置参数”。
Sybase SQL Anywhere数据库恢复工具ReadASADB：
之前就已经研发成功了能够从Sybase SQL Anywhere的DB文件中恢复数据的工具: ReadASADB。此工具支持ASA v5.0, v6.0, v7.0, v8.0, v9.0, v10.0, v11.0, v12.0, v16.0, v17.0等版本。
能够从损坏的SQL Anywhere数据文件(.db)和UltraLite数据文件(.udb)上提取数据的非常规恢复工具。
恢复Sybase SQL Anywhere的工具在国内处于领先水平。
Sybase SQL Anywhere数据库恢复工具ReadASADB功能
能够从损坏的SQL Anywhere数据文件(.db)和UltraLite数据文件(.udb)上提取数据的非常规恢复工具
- 适用于所有的SQL Anywhere版本 包括：5.x,6.x,7.x,8.x,9.x,10.x,11.x,12.x,16.x,17.x
- 适用于所有的UltraLite版本
- 能够恢复出来表结构和数据
- 能够恢复自定义数据类型
- 能够恢复存储过程等对象的语法
- 能够导出到目标数据库
- 能够导出到SQL文件并生成导入脚本
- 支持多种字符集，包括：cp850、cp936、gb18030、utf8等
- 能够恢复未加密或者简单加密类型的数据
- 简单易用
- 限制：不支持AES加密的数据文件
SQL Anywhere数据库非常规恢复工具ReadASADB使用介绍
Sybase SQL Anywhere数据库恢复工具ReadASADB适用场景
各种误操作：
- 误截断表(truncate table)
- 误删除表(drop table)
- 错误的where条件误删数据
- 误删除db或log文件
- 误删除表中的字段
Sybase SQL Anywhere数据库恢复工具ReadASADB的应用场景：
1.因为物理磁盘故障、操作系统、系统软件方面或者掉电等等原因导致的Sybase SQL Anywhere数据库无法打开的情况；
2.误操作，包括truncate table,drop table,不正确的where条件导致的误删除等；
Sybase SQL Anywhere无法打开时，比较常见的错误是：Assertion failed。
如：
1、Internal database error *** ERROR *** Assertion failed:201819 (8.0.1.2600) Checkpoint log: invalid bitmap page -- transaction rolled back
2、Internal database error *** ERROR *** Assertion failed:201819 (8.0.1.2600) Page number on page does not match page requested -- transaction rolled back
3、Internal database error *** ERROR *** Assertion failed:200502 (9.0.2.2451) Checksum failure on page 23 -- transaction rolled back
4、File is shorter than expected
5、Internal database error *** ERROR *** Assertion failed: 201116 Invalid free list index page found while processing checkpoint log -- transaction rolled back
6、*** ERROR *** Assertion failed: 51901 Page for requested record not a table page or record not present on page
7、*** ERROR *** Assertion failed: 201417 (7.0.4.3541) Invalid count or free space offset detected on a table page
8、Internal database error *** ERROR *** Assertion failed: 201425 (8.0.3.5594) Invalid count or free space offset detected on a free list page -- transaction rolled back.
9、Internal database error *** ERROR *** Assertion failed: 100702 (8.0.1.2600) Unable to modify indexes for a row referenced in rollback log -- transaction rolled back
Sybase ASE数据库恢复工具READSYBDEVICE：
一个不依赖数据库管理系统、直接从Sybase数据库设备文件上提取数据的业内领先的恢复工具！能够从损坏的Sybase ASE设备文件(.dat)上提取数据的非常规恢复工具。
Sybase ASE数据库恢复工具READSYBDEVICE的主要功能：
- 被勒索病毒加密数据文件及备份文件情况下的恢复；
- 系统崩溃只剩下数据文件的情况下的恢复，甚至数据库文件不存在而只有损坏的备份文件情况下的恢复；
- 因断电、硬盘坏道等造成数据库文件损坏情况下的恢复；
- delete数据恢复、误update数据恢复、误删除表(drop）恢复、误truncate表恢复 等；
- 各种Sybase内部系统表损坏、索引错误的修复；
- master数据库损坏而无法正常运行情况下的恢复；
- Sybase数据库被标记为可疑，不可用等情况的恢复；
- Sybase数据库中数据文件内部出现坏块情况下的恢复；
- Sybase数据库无数据文件但有日志文件的情况下的恢复；
- Sybase数据库只有数据文件无任何日志文件的情况下的恢复；
- Sybase数据文件被误删除情况下的碎片提取恢复；
- 磁盘阵列上的Sybase数据库被误格式化情况下的数据库恢复；
- 数据库sysobjects等系统表损坏无法正常应用情况下的恢复；
- Sybase数据库还原数据库出现失败情况下的恢复；
- Sybase数据库只剩下损坏的备份文件情况下的恢复。
Sybase ASE数据库恢复工具READSYBDEVICE支持的版本：
Sybase ASE 11.0.x，11.5.x，11.9.x，12.0.x，12.5.x，15.0.x，15.5.x，15.7.x，16.0.xSQL Server数据库恢复工具SQLRescue：
一个不依赖数据库管理系统、直接从SQL Server数据库文件上提取数据的业内领先的恢复工具！能够从损坏的SQL Server数据库文件(.mdf)上提取数据的非常规恢复工具。
SQL Server数据库恢复工具SQLRescue的主要功能：
- 系统崩溃只剩下数据文件的情况下的恢复，即无日志文件或者日志文件损坏情况下的恢复；
- 断电导致数据库文件损坏情况下的恢复；
- 硬盘坏道造成数据库损坏情况下的恢复；
- 数据文件内部存在坏页情况下的恢复；
- 企业管理器误删除数据表记录，管理软件误删除数据表记录的恢复；
- 并闩锁错误、格式化、误删除后导致软件不能使用的情况；
- 无法读取并闩锁页sysindexes失败情况下的修复；
- 数据文件被误删除情况下的碎片提取恢复；
- 系统表损坏、索引错误、误删除数据库表、删除记录的数据找回；
- master数据库损坏而无法正常运行情况下的恢复；
- 数据文件无法附加情况下的数据恢复；
- 数据库被标记为可疑，质疑，不可用等情况的恢复；
- 数据库sysobjects等系统表损坏情况下的恢复；
- 数据被误(drop、delete、truncate）删除表数据的恢复,误update后的数据恢复等；
- 还原时报一致性错误，错误823等情况下的数据恢复，各种错误提示的数据库文件修复；
- 数据库被误格式化等情况下的数据库恢复；
- 日志收缩造成数据库损坏情况下的恢复；
- 仅剩损坏的备份文件情况下的恢复。
SQL Server数据库恢复工具SQLRescue技术特点：
只要SQL Server数据库的数据文件存在，我们就有办法帮您从数据文件中找回重要数据。- 从数据文件中直接恢复数据
- 不能附加时直接恢复数据并生成新的数据库
- 系统表损坏的数据库修复
- 快速修复SQL 823错误、连接中断错误
SQL Server数据库恢复工具SQLRescue支持的版本：
Microsoft SQL Server 7.0, 2000, 2005, 2008, 2008R2, 2012, 2014, 2016, 2017,2019。+-------------------------------------华丽的分割线-------------------------------------------------------------------------
提供Sybase ASE及Sybase SQL Anywhere数据库修复服务，电话: 13811580958(微信)，QQ: 289965371！We have many years of experience in recovering data from damanged Sybase devices. Contact us by Phone: +86 13811580958 Wechat: 13811580958 Email: 289965371@qq.com
京ICP备2020043699号-2
Powered by WordPress | SiteMap | Baidu Knows | Google Knows | About
