典型数据

典型数据（精选8篇）

典型数据 篇1

1 线缆

布线标准认可多种介质类型以支持广泛的应用，但是建议新安装的数据中心宜采用支持高传输带宽的布线介质以最大化其适应能力并保持基础布线的使用寿命。

推荐使用的布线传输介质有：

(1)100Ω平衡双绞线，建议6类/E级(GB 50311-2007)、6A类/EA级(ANSI/TIA/EIA-568-B.2-10,ISO/IEC 11801:2008)或F/FA级(GB 50311-2007,ISO/IEC 11801:2008)

(2)多模光缆：62.5/125μm或50/125μm(ANSI/TIA/EIA-568-B.3)，建议选用50/125μm,850nm工作波长的激光优化多模光缆(ANSI/TIA/EIA-568-B.3-1)

(3)单模光缆(ANSI/TIA/EIA-568-B.3)

除以上介质外，认可的同轴介质为75Ω(型号是734和735)同轴电缆(符合Telcordia GR-139-CORE)及同轴连接头(ANSI T1.404)。这些电缆和连接头被建议用于支持E-1及E-3传输速率接口电路。

在数据中心机房设计时，应根据机房的等级、线缆的敷设场地和敷设方式等因素选用相应的线缆，使其：

◆灵活支持所对应的服务;

◆具有长久的使用寿命;

◆尽量减少占用空间;

◆具有更好的布线信道传输容量;

◆满足设备制造商的推荐。

2 机柜/机架

机架为开放式结构，一般用于安装配线设备，有2柱式和4柱式。机柜为封闭式结构，一般用于安装网络设备、服务器和存储设备等，也可以安装配线设备，有600×600、6 0 0×8 0 0、6 0 0×9 0 0、6 0 0×1 0 0 0、600×1200、800×800、800×1000、800×1200等规格。宽度为600mm的机柜没有垂直线槽，一般用于安装服务器设备;宽度为600mm的机柜两侧有垂直线槽，适合跳线较多的环境，一般作为配线柜和网络柜。机架和机柜最大高度为2.4m，推荐的机架和机柜最好不高于2.1m，以便于放置设备或在顶部安装连接硬件。推荐使用标准19″宽的机柜/机架。机柜/机架的构成如图1所示。

机柜深度要求足够安放计划好的设备，包括在设备前面和后面预留足够的布线空间、装有方便走线的线缆管理器、电源插座、接地装置和电源线。为确保充足的气流，机柜深度或宽度至少比设备最深部位多150 mm(6 in)。

机柜中要求有可前后调整的轨道。轨道要求提供满足42U高度或更大的安装空间。

3 配线架

为提高与满足企业的成本效益要求，数据中心要求能够提供更高密度的设备以及应用空间。因此，在数据中心中使用的配线架应能满足高密度安装配线模块，方便端口的维护或更换，并且能清楚方便地对端口进行识别的要求。

模块化的配线架可以灵活配置机柜/机架单元空间内的端接数量，既减少端口浪费又便于日后的维护变更。配线架的构成如图2所示。

常用的配线架，通常在1U或2U的空间可以提供24个或48个标准的RJ45接口，而使用高密度配线架可以在同样的机架空间内获得高达48个或72个标准的RJ45接口，从而大大提高了机柜的使用密度，节省了空间。高密度配线架的构成如图3所示。

角型配线架允许线缆直接从水平方向进入垂直的线缆管理器，而不需要水平线缆管理器，从而增加了机柜的密度，可以容纳更多的信息点数量。角型高密度配线架的构成如图4所示。

凹型配线架主要应用在服务器机柜背部进行配线的情况下，配线架向下凹陷，即使关闭服务器机柜的背板，也不会压迫到任何的跳线，且方便维护操作人员快捷的接入整个配线界面。凹型高密度配线架的构成如图5所示。

机柜内的垂直配线架，充分利用机柜空间，不占用机柜内的安装高度(所以也叫0U配线架)。在机柜侧面可以安装多个铜缆或者光缆配线架，它的好处是可以节省机柜空间，减少跳线的弯曲和更方便地插拔跳线。

高密度的光纤配线架，配合高密度的小型化光纤接口，可以在1U空间内容纳至少48芯光纤，并具备人性化的抽屉式或翻盖式托盘管理和全方位的裸纤固定及保护功能。更可配合光纤预连接系统做到即插即用，节省现场施工时间。光纤高密度配线架的构成如图6所示。

4 线缆管理器

在数据中心中通过水平线缆管理器和垂直线缆管理器实现对机柜/机架内空间的整合，提升线缆管理效率，使系统中杂乱无章的设备线缆与跳线管理得到很大的改善。水平线缆管理器主要用于容纳内部设备之间的连接，有1U和2U、单面和双面、有盖和无盖等不同结构组合，线缆可以从左右、上下出入，有些还具备前后出入的能力。垂直线缆管理器分机柜内和机柜外两种，内部的垂直线缆管理器主要用于管理机柜内部设备之间的连接，一般配备滑槽式盖板;机柜外的垂直线缆管理器主要用于管理相邻机柜设备之间的连接，一般配备可左右开启的铰链门。线缆管理器的构成如图7所示。

5 设备线缆与跳线

在数据中心中通过设备线缆与跳线实现端口之间的连接。设备线缆与跳线可采用铜缆或光纤。它们的性能指标应满足相应标准的要求。

光、电设备线缆与跳线应和水平或主干光(电)缆的等级保持一致，还应与网络设备、配线设备端口连接硬件的等级保持一致，并且能够互通。

在端口密集的配线和网络机柜/机架上，可以使用高密度的铜缆和光纤跳线。这些跳线通过对传统插拔方式或接口密度的重新设计，在兼容标准化插口的前提下提高了高密度环境的插拔准确性和安全性。线缆/跳线的构成如图8所示。

6 预连接系统

预端接系统是一套高密度，由工厂端接、测试的，符合标准的模块式连接解决方案。预连接系统包括配线架、模块插盒和经过预端接的铜缆和光缆组件。预端接系统的特点是经过工厂端接和测试的铜缆和光缆可以提供可靠的质量和性能;基于模块化设计的系统允许安装者快速便捷地连接系统部件，实现铜缆和光缆的即插即用，降低系统安装的成本;当移动大数量的线缆时，预端接系统可以减少移动所带来的风险;预连接系统在接口、外径尺寸等方面具有的高密度优点节省了大量的空间，在网络连接上具有很大的灵活性，使系统的管理和操作都非常方便。预连接系统的构成如图9-1和图9-2所示。

7 线缆/跳线标签系统

与连接硬件相同，线缆/跳线标签系统也分为三大类对应三种类型的打印机。

单根线缆/跳线标签最常用的是覆膜标签，这种标签带有粘性并且在打印部分之外带有一层透明保护薄膜，可以保护标签打印字体免受磨损。除此之外，单根线缆/跳线也可以使用非覆膜标签、旗式标签、热缩套管式标签。单根线缆/跳线标签的常用的材料类型包括：乙烯基、聚酯和聚氟乙烯。

对于成捆的线缆，建议使用标识牌来进行标识。这种标牌可以通过尼龙扎带或毛毡带与线缆捆固定，可以水平或垂直放置。标签固定方式如图10所示。

所有需要标识的设施都要有标签。建议按照“永久标识”的概念选择材料，标签的寿命应能与布线系统的设计寿命相对应。建议标签材料符合通过UL969(或对应标准)认证以达到永久标识的保证;同时建议标签要能达到环保RoHS指令要求。标签从结构上可分为粘贴型和插入型标签，所有标签应保持清晰、完整，并满足环境的要求。标签应打印，不允许手工填写，应清晰可见、易读取。特别强调的是，标签应能够经受环境的考验，比如潮湿、高温、紫外线，应该具有与所标识的设施相同或更长的使用寿命。聚酯或聚烯烃等材料通常是最佳的选择。

典型数据 篇2

市政务服务和大数据管理局围绕“我为企业解难题”和“我是志愿者我来帮”制定了详细的实施方案，组建了优化营商环境服务队，签订了优化营商环境承诺书，引导党员干部树牢“优化营商环境人人有责”的理念，让机关党组织成为优化营商环境的坚强战斗堡垒。

一、发挥大数据集聚效应，助力企业纾困赋能

一是为破解中小企业融资难、融资慢、成本高等问题，该局建成全省首个普惠金融平台，更好地为企业提供精准的金融服务。

截至目前，平台完成授信额度*亿元。二是依托通信大数据技术，开展疫情防控跨区域协查。截至目前，已核查中高风险来鹤人员信息*万条，准确率达*%，为企业拉好疫情防控“防护网”。三是为促进我市房地产企业健康发展，会同不动产登记中心等部门实现了网上交税，在全省率先实现了不动产证家门口办理。

二、提升政务服务效能，助力企业高质量发展

一是优化窗口布局，设立企业开办服务专区，实行“一窗办理”，*个工作日即可办结。

二是针对企业办理高频事项，实行周六延时服务、上门服务，对服务大厅升级改造，增设企业代办等*个专区。三是突破改革瓶颈，实行容缺办理、并联审批、联合验收，率先实现“一书三证”电子证照审批应用，工程项目手续时限压缩至*个工作日以内。建立代办专员制度，提供管家式服务、延时服务，为企业解决问题*个。四是从人大代表、政协委员、老干部代表、企业服务管家、企业代表中聘任*名政务服务监督员，为企业群众发声代言。

三、深化交易领域改革，助力企业减负增效

一是加快推进公共资源交易电子化进程。

充分发挥大数据优势，运用信息技术、云计算等方式，全面推行交易全程电子化、远程不见面开标，实现了招标项目从进场、开标、评标全程在线、闭环管理。今年年初以来，已为投标企业节省费用约*万元。二是创新服务方式，推进公共资源交易全流程“一网通办”、全免费服务，拓展电子保函、投标贷、中标贷等供给侧金融服务链条。对违规交易主体施行联合惩戒，限制失信企业参与招投标活动。截至*月底，平台完成交易项目*个，交易额*亿元，节约zf资金达*亿元。三是优化交易服务流程，降低交易成本。全面取消招标文件资料收费和纸质招标文件，实行线上全流程电子化交易，为投标企业节约支出*余万元。

四、党建引领，助力灾后恢复重建、疫情防控

一是及时出台灾后恢复重建、疫情防控服务保障措施。

在全市各级行政服务大厅设置“绿色通道”受理窗口，对灾后恢复重建、疫情防控项目统一受理、快速审批。灾后恢复重建项目由行政服务中心工作人员负责全程代办，为受灾企业和群众提供“一站式”“保姆式”服务。在*市普惠金融共享平台开设“防汛救灾”和“抗疫复产”服务专区，上线“复工贷”“救灾贷”“防汛帮扶贷”等金融产品。

840D数据恢复典型故障处理 篇3

故障1一台用840D数控系统改造的俄罗斯车削加工中心, 由于维修需重装PLC程序, 为安全起见, 先将现有的PLC程序利用系列启动备份到数控系统硬盘上, 再将PLC清空, 然后找到数控系统硬盘上以前在正常情况下备份的PLC压缩文件进行回装, 但在回装完成后, 总是出现“PLC未启动”报警。

分析处理:由于之前已用STEP7软件将该机床的PLC原程序备份到外部PC的硬盘上, 所以决定用STEP7软件将该程序重新下载到机床NCU中, 步骤如下:

(1) 用适配器和通信电缆将PC和NCU连接后, PC和机床上电。

(2) 进入STEP7操作界面, 打开已发现的“节点”列表, 在有“PLC未启动”报警状态下, STEP7并未发现PLC的节点地址 (其地址为6) , 所以无法将PLC程序下载到NCU中。

(3) 在NCU面板上清空PLC后, PLC节点出现在STEP7节点列表中, 但其内容为空, 此时打开PC上备份的PLC原程序将其下载。

(4) 下载完成后, 机床仍会出现“PLC未启动”报警, 此时进入到已下载的PLC程序中, 点击“PLC”→“Diagnostics/Settings”→“Opreating Mode”→“Start-up”来启动PLC。

由于840D系统具有版本差异性, 即存在数据处理、数据存储功能的高低端差异, 因此在回装数据之前, 最好将NC及PLC数据执行总清, 使NCK RAM和PLC RAM中的内容全部清空, 回到出厂状态, 这样恢复数据可以避免出现一些数据回装导致的故障。若在清空后回装仍会出现上述情况, 即可采用以上方法来处理, 前提是必须先用STEP7在外部PC中备份PLC原程序。

故障2一台840D国产数控镗床, 系统在初始自检时出现蓝屏及报警字符, 反复自动重启, 无法正常引导。用相同型号的PCU50替换此机床的PCU50, 开机正常进入HMI操作界面, 但出现了“列表中报警文本已满, 文本数过大, F:dhmb.dirmyplc_ch.com未找到”的报警。将替换的备份PCU50硬盘上的NC数据, 重装到NCU后, 出现了新的故障:OP面板所有操作软键均失灵, 不能操作, 但机床控制键盘上的按键均有效。重新关机再开机, 故障依旧, 之前的报警也存在。

分析处理: (1) 由于OP面板失灵, 不能操作, 所以不能进入回装数据界面, 只能执行NC和PLC的总清, 使所有数据都回复到出厂默认值; (2) 在清空PLC数据之前, 为了确保数据不丢失, 使用STEP7软件将机床的PLC程序上传到PC, 以做备份之用; (3) 回装原机床NC卡中备份的NC数据和PLC数据, 数据恢复后, OP可以正常操作; (4) 经查找确认此PCU50硬盘中的“myplc_ch.com”文件丢失, 从相同机床PCU50里复制文件到此机床上, 报警解除。

840D是由NC-CPU、PLC-CPU及MMC-CPU3个微处理器组成的数控系统, 在功能上既相互分工, 又相互协调通信, 工作时进行数据交换及存储。只要发生数据传输、存储和交换, 就有可能产生数据通信引起的故障, 即此机床PLC与替换的PCU50中的MMC及NC数据之间通信故障引起的异常, 其他机床上的NC数据不一定能与本机床的PLC数据匹配, 所以才导致OP面板操作按钮失灵。机床报警的原因是由于更换的PCU50里并没有与原PLC程序相匹配的报警文本myplc_ch.com文件。如果要使用恢复数据恢复系统, 最好应还原此机床的数据。机床在出厂时NC、PLC及MMC数据相互间是匹配的, 才能正常通信, 若安装不匹配的数据, 可能会导致一些系统故障。

故障3一台德国进口数控车铣复合加工中心, 系统为西门子840D SolutionLine, 机床出现“PLC不能被控制”报警, 无法消除, 机床不能正常工作。

分析处理: (1) 执行NC和PLC总清, 将所有数据恢复到缺省值, 使其报警解除; (2) 调出PLC的文档数据, 装入NCU中, 结果在装入过程中, 系统出现报警对话框, 显示“内存不足”报警, 导致回装数据失败, 重复尝试, 结果相同; (3) 将NC及PLC总清, 先装入NC数据, 没有出现报警提示, 再装入PLC数据, 也没有出现报警提示, 装载成功, 并且开始的报警也没有再出现, 故障排除。

有些NCU执行NC及PLC总清之后, 在回装数据时, 要先装载NC数据, 最后装载PLC数据。因为NCU里SRAM根据版本不同而容量有所差别, 对于个别840D系统, 其中NCU的SRAM还存在内部的内存容量分配问题及NC分配内存的参数问题, 所以回装数据时应注意, PLC的CPU与NC的CPU在物理结构上两者合为一体, 合成在NCU中, 但在逻辑功能上相互独立。它把所有CNC、PLC和通信任务综合在单个NCU模块中, 若先装PLC数据, 则PLC数据会占用NCU中的SRAM, 因而会出现多次“内存不足”报警提示, 且在机床系统配置数据的时候, 要先配置NC的数据, PLC的许多BLOCK是围绕NC数据来生成的。为避免发生这种回装数据出现的“内存不足”故障, 所以在经过总清NC和PLC后, 回装数据时, 还是先回装NC数据, 再回装PLC数据为佳。

综上所述, 在需要更换NC、PLC数据, 执行NC及PLC总清时, 要按照840D调试手册上的方法来执行, 为避免产生一些恢复数据引起的报警及故障, 回装时最好选择以下的方法: (1) 建议先备份NC和PLC数据, 再执行NC及PLC总清; (2) 总清完成后, 先装入NC数据, 再装入PLC数据; (3) 在无法得知PLC是否有备份的情况下, 可借助STEP7将PLC上传到电脑里备份, 需要时可以再将PLC程序下载到NCU中; (4) 还原数据时, 应还原此机床的数据, 使数据之间可以更加匹配, 否则会导致一些系统故障。

摘要：介绍几例西门子840D系统数据恢复回装过程中的典型故障现象及处理。

典型数据 篇4

一、云模型的介绍

云模型主要是定性和定量转换的模型。在模糊数学和随机数学的基础上采用云模型来统一描画出语言值中存在的大量随机性、模糊性和二者间的关联性。用云模型来表示自然语言中的基元即语言值, 用云的数字特征即期望、熵以及超熵来表示语言值的数学性质。它既体现了代表定性概念值的样本中的随机性, 又体现了隶属程度的不确定性, 从而展示了随机性和模糊性之间的关联。目前, 云模型被广泛的应用到信任评估、图像分割和时间序列挖掘等领域上。

二、大数据典型相关分析的现状

人们在工程实践项目和科研工作中收集到的大量数据大部分都具备大数据的特性, 但是把大数据作为一个独立的科学来研究是比较新鲜的。其主要相关的研究领域有:生物信息领域, 一部分学者研究了生理电大数据的压缩和存储等方面问题, 将生物学研究中的搜集到的数据可以看做大数据;数据挖掘领域, 一些科学家研究了大数据挖掘中存在的在线特征的选择问题;大数据程序开发以及存储方面, 一些科学家研究了大数据和云计算现状等。在现阶段, 大数据研究过程中, 还存在诸多不成熟的地方, 需要对其进行进一步的完善。虽然一些学者探讨了在云计算平台下的大数据存储方法, 但是并没有对大数据典型相关分析进行研究, 也没有提出云模型下的大数据典型相关分析方法, 使得这一类的研究比较缺乏, 因此, 就需要加强对大数据典型相关分析的研究, 提出切实可行的方法, 从而完善大数据典型相关分析, 来满足大数据研究的需求。

三、基于云模型下的大数据典型相关分析方法

1、执行大数据典型相关分析的流程。大数据典型相关分析的流程包括:首先, 在各个云端上依据当前云端中的数据, 运用逆向云发生器形成云数字特征;其次, 把各个端点云传送到中心云端, 采用多维云进行合并, 最终在中心云端中生成中心云;再者, 依据中心云, 采取正向云发生器生成中心云滴;最后, 在中心云滴上实行典型相关分析。2、端点云的生成方法。利用逆向云发生器, 在云端中的数据中生成云, 就是端点云的生成过程。本文主要采用的是多维的逆向正态云发生器。为了提高在大数据中多维逆向正态云发生器生成云的效率, 可以在随机采样的方法下, 采取启发式的策略生成云。3、多维云的合并方法。在进行多维云合并时, 每次只能进行一对云的加法计算。当采用反复调用方式使, 每合并一次云, 其新生云需要加入合并的操作中, 使云的总体数量只能减少一个, 大大降低了合并的效率。在大数据的背景下, 由于受到数据存储或者收集方法的影响, 就会使不同云端产生的数据也不尽相同, 因此, 在合并各个云端传递到中心云端的云时, 要充分地考虑各云端数据的差异。

四、影响大数据典型相关分析方法的因素

1、中心云滴群的大小。随着云滴群的规模不断的扩大, 典型相关分析的系数误差也逐渐下降, 当达到一定程度时, 其下降的速度趋向平缓的状态。这就显示出适当的增大云滴群的规模, 可以有效地降低典型相关系数误差, 通过少量的云滴可以体现了大数据中包含的相关性。2、云端数量。不同云端数量对典型相关系数的误差有着不同的差异性, 当云端数量不断增多时, 其运行的速度也相对提高。3、数据容量。随着数据容量的不断增大, 其对应的典型相关系数的误差也随之上升。在大数据环境下, 典型相关分析系数的误差有一定的波动性, 同时期上升的幅度比较小。

五、总结

基于云模型的大数据典型相关分析方法主要是在小容量的中心云滴群中进行典型相关分析操作, 从而提高在大数据环境下执行典型相关分析的效率。为了能够快速生成中心云滴, 改进了多为逆向正态发生器, 进而提高了大数据下云的生成效率。同时也总结了多维云合并计算的方法, 提升了云合并的速度和质量。为之后类型的研究工作提供了可靠的理论依据, 进一步完善了云模型的大数据典型相关方法。

参考文献

[1]杨静, 李文平, 张健沛.大数据典型相关分析的云模型方法[J].通信学报, 2013, 34 (10) :122-133.

[2]顾鑫, 徐正全, 刘进.基于云理论的可信研究及展望[J].通信学报, 2011, 32 (7) :176-181.

典型数据 篇5

关键词：数据绑定控件,典型用法

在ASP.NET中, GridView是使用的最多的数据绑定控件, 但是大部分只是用它来显示数据, 很少考虑到用户的操作习惯, 可操作性很差, 因此本文以访问常用示例数据库Northwind为例, 介绍在网站设计中GridView的典型用法, 使它具有良好的交互性。

1 通过PageIndexChanging事件实现对GridView控件的分页

1) 当GridView控件读取大量的数据时, 数据记录往往无法在当个页面中完全呈现, 这时需要对GridView控件进行分页, ASP.NET中的GridView有一个内置的分页功能, 可支持基本的分页, 用户可以对GridView进行默认分页或创建自定义的分页;

2) 创建一个网站, 默认主页为Default.aspx, 在Default.aspx文件中添加一个GridView控件, 并将AllowPaging属性设置为true;

3) 在Default.aspx.cs文件中引入命名空间System.Data.SqlClient;

在Page_Load事件中实现GridView显示数据, 在PageIndexChanging事件中实现分页功能, 代码如下:

2 在GridView控件中实现自动编号及定制GridView控件外观

1) 当页面比较多时, 往往需要在GridView中增加一列自动递增序号列, 用来标识每一行的序号。在步骤1的基础上继续完善GridView的功能。

选中GridView右上角的智能标记点击“添加新列”, 添加一个模板数据绑定列TemplateField, 并在ItemTemplate模板中添加一个Label控件用于显示编号序列。代码如下:

当鼠标悬停在某一行时, 效果如下图, 交互性更好。

参考文献

[1]孟庆昌.ASP.NET网站开发先锋.机械工业出版社, 2010, 2.

典型数据 篇6

关键词：嵌入式数据库,SQLite数据库,Wince

0.前言

随着嵌入式系统的软硬件平台和功能多种多样, 嵌入式芯片功能的逐渐增强和现实对嵌入式系统功能要求的逐渐提高, 在嵌入式系统中逐渐要求使用数据库, 导致了嵌入式数据库系统的应用环境的要求也非常丰富多样, 其结构和采用的技术手段因为不同的需求而多种多样, 总的来说, 嵌入式数据库系统从结构上可以分为两大模块:外壳和内壳。嵌入式数据库体系结构具体见图1。

SQLite作为一款轻型的数据库, 它的设计目标是针对嵌入式产品的, 由于它占用资源非常的低, 可能只需要几百K的内存就够了, 就能在嵌入式设备中使用。相对于传统嵌入式数据库, SQLite数据库具有较好的实时性、系统开销小、底层控制能力强的特点, 并且能够高效地利用嵌入式系统的有效资源, 提高数据的存取速度, 增强系统的安全性。同时它能够支持Windows/Linux/Unix等等主流的操作系统, 还能够跟PHP、Perl、Tcl、C#、Java、Python等很多程序语言相结合, 还有ODBC接口, 同样比起Mysql、PostgreSQL这两款开源世界著名的数据库管理系统来讲, 它的处理速度比他们都快。

1、SQLite的技术特点和内部结构

SQLite作为开源的轻量级的嵌入式关系数据库, 本身有三级模式结构体系, 即用户模式、逻辑模式和存储模式, 结构紧凑, 可靠性强, 其具有如下特点:

(1) 支持ACID事务, SQLite数据库不需要安装和管理配置, 在系统崩溃或失电之后可自动恢复, 不会出现数据丢失现象。

(2) 支持标准SQL, 只需要掌握3个核心API函数, 大多数的SQL语句都可以使用。特别是SQLite支持视图、触发器, 支持嵌套SQL。

(3) SQLite不同于Server数据库, 没有中间服务器进程。在使用SQLite时, 访问数据库的程序直接从磁盘上的数据库文件读写。

(4) 占用较少的存储器空间, 存储量大, SQLite完全独立, 数据库引擎和应用程序在同一系统进程中, 最高能支持2TB的数据库, 运行速度较MySQL快1～2倍。

(5) 可靠性较好, SQLite数据库的API简单、易用, 有良好注释的源代码, 支持多种语言和多个嵌入式操作系统平台, 像C/C++/C#、Linux系统

(6) 无数据类型的限制。SQLite最大的特点在于其数据类型为无数据类型 (Typelessness) 。无论这列声明的数据类型是什么, 可保存任意类型的数据到所想要保存的任何表中的任何列。在生成表结构时要声明每个域的数据类型, 但SQLite并不做任何检查。

SQLite的体系结构如图2所示, 包括内核、SQL编译器、后端/后台以及附件4个部分。该体系结构的核心是虚拟数据库引擎 (VDBE) , VDBE完成与数据操作相关的全部任务, 是客户和存储之间信息交换的中间单元, 分为操作系统接口层、存储管理层、虚拟机层及用户接口层。

其中内核是标记处理器 (tokenize) 和分析器 (parser) SQLite有自己高度优化的代码生成器, 可以快速、高效地生产出代码;SQL编译器完成SQL语句的接收、提取、执行;而后台是经过优化的B树, 这样有助于运行在可调整的页面缓冲上时, 对磁盘的查找降低到最小。再往下是页面高速缓存, 它作用在OS的抽象层之上, 这样的体系结构使数据库的可移植性变为可能。分别完成SQL指令对系统函数的调用进而执行这些指令;附件包括常用内存定位和哈西表等工具和部分Assert和MD5等测试代码。

2. SQLite数据库的应用开发

2.1 准备编译WinCE平台所需要的SQLite库文件

SQLite编译主要有以下几个步骤:

(1) 首先到http://www.sqlite.org/download.html网站下载最新的SQLite源代码包, 解压后将生成sqlite目录, 另外新建并转到一个与sqlite目录平行的同级目录, 如project目录。

(2) 在Visual C++中创建项目工程, 选择Pocket PC 2003平台;创建一个“Win32智能设备项目”;选择一个空dll项目应用程序类型;

将下载之后的文件解压放到dll项目的工程目录之下。删除其中的tclsqlite.C和shell.C文件。

(3) 修改相关代码和属性设置

在预处理器中添加“SQLITE＿ENA＿BLE COL-UMN METADATA”;

模块定义文件:“sqlite3.def”;

将fts3＿taokenizer.C和fts3.c文件中的宏SQLITE＿EXTENSION＿INITl修改为“extern const sqlite3＿api＿routines*sqlite3＿api;”。

修改项目属性中创建/使用预编译头:“不使用预编译头”;

2.2 SQLite数据库应用基础, 和所有数据库一样的步骤

(1) 连接打开数据库及数据库操作函数

如果调用成功会返回SQLITE＿OK, 否则返回错误码。

(2) 构造SQL语句并执行

这和SQLite本身无关, 根据需要使用适当的方法构造, 注意传给SQLite函数的时候, 字符串编码要记得转换为UTF8/UTF16

(3) 执行SQL语句, 获取查询结果

(4) 关闭数据库函数

2.3 在WinCE应用软件中调用SQLite数据库 (1) 加载动态库和参数文件。

在项目中直接调用SQLite动态库, 将编译生成dll文件和1ib文件以及sqlite3.H

定义数据库:sqllte3*db=NULL:

记录错误信息:char*zErrMsg=O;

(2) 打开数据库

如果数据库打开成功, 则返回值为0;如果返回值不为0, 则可以根据返回值在sqlite3.h文件中查看数据库打开失败的原因。

打开数据库函数:int sqlOpen;sqlOpen=sqlite3＿open (FileRoot, &db) ;

打开失败, 返回:if (sqlOpen!=SQLITE＿OK) re-turn;

(4) 启动、结束事务处理:

(5) 执行SQL语句函数

3. 嵌入式数据库SQLlite的应用成果

SQLite作为一款小巧的嵌入式数据库, 发展前景很大, 在基于ARM的Wince操作系统有着广泛应用。目前, 随着智能手机的快速发展, 智能手机平台将成为GIS技术和互联网新的应用平台。以Google Map Api的导航应用为基础, 实现了一种基于Android和SQLite数据库的应用, 能够给用户提供智能化的地质数据地图导航服务。

而且SQLite数据库已经广泛应用于嵌入式家居能源控制系统的数据处理, 在家居能源控制系统中将实现设计成以数据管理为基础的方式, 通过嵌入式数据库系统有效地组织和管理家居中的各类数据, 从而达到控制系统实时查询、控制等功能的设计要求。所有对数据库的操作都在保证数据安全的前提下进行。

在嵌入式系统的数据管理中, SQLite都表现出了良好的应用效果, 为应用程序运行效率的提升提供了后台保障。

参考文献

[1]http://www.sqlit.org官方网站, 包括各种资料和源代码

[2]http;//WWW.sqlite.com.cn SQLite中文网站, 包括各种中文资料和应用文档

[3]龚星宇, 许佳, 龚尚福.嵌入式数据库的研究.现代电子技术[J], 2007

[4]唐敏, 宋杰.嵌入式数据库SQLite的原理与应用[J].电脑知识与技术, 2008

[5]太东, 卢秉亮等.嵌入式数据库SQLite在Windows程序中的应用[J].沈阳航空工业学院学报, 2009, 26[硕士学位论文]

典型数据 篇7

关键词：日常信息,处理思路,代价信息

1平时的信息收集和维护工作

为了更好地处理可能出现的性能问题, 需要在平时就注意积累操作系统、数据库的日常运行信息, 这样可以了解系统的运行特点和基本负荷变化情况, 当数据库出现性能问题的时候, 这些都是非常有用的信息。

收集Informix数据库的日常信息, 最简单的可以仅观察onstat-p的输出结果, 和数据库性能相关的主要是读缓存率 (第一个%cached) 、写缓存率 (第二个%cached) 、顺序扫描数 (seqscans) 。读缓存率不应该低于90%, 否则就应该关注顺序扫描数, 找出经常被顺序扫描的大表, 创建相应索引或修改应用SQL, 必要时还需要增加数据库BUFFERS。写缓存率通常不应该低于85%, 不过由于受到应用写库的方式和LRU设置的影响, 稍微低一些也可以接受。

数据库日志中记录的检查点持续时间 (checkpoint duration time) 也需要关注, 性能良好的实例中, 该值不超过3秒。在日常维护时, 注意定期收集数据库的统计信息 (update statistics) , 如果担心库太大, 在业务空闲期间无法完成, 至少应该对变化比较频繁的大表针对索引中的第一个字段收集统计信息, 语法:update statistics for table my_tab (col1) ;

当性能问题出现后, 可以按如下步骤来定位问题:

首先应该利用操作系统命令查看一下当时操作系统状态:CPU/IO/SWAP, 是否和平时差别很大;查看操作系统日志是否最近有异常报错;检查数据库日志, 看看是否有断言错误 (Assert Failed) , 是否有数据库内部错误发生, 数据库的检查点持续时间相比平常是否有显著增加。确认是数据库性能出现了问题, 就可以借鉴下文列出的常见典型情况, 迅速排查解决问题。

2常见典型性能问题现象及解决建议

数据库经常出现的性能问题, 基本可以归结为以下类型。下面根据各种典型类型谈一下具体的现象和解决办法:

(1) 数据库应用突然变慢, 查看系统信息, 发现CPU空闲突然很低, IO性能没有明显恶化。这种情况最常出现在新应用上线时, 由于应用SQL未恰当使用索引造成……

首先, 需要排除操作系统上其他应用程序的问题。通过top (HP) /topas (AIX/Linux) 命令可以看到当前占用CPU资源最多的进程, 确认是oninit进程。Solaris上默认没有top命令, 可以通过/usr/ucb/ps-aux|more的方式来查看, 该输出是根据CPU占用情况来排序的。

数据库进程占用了大量CPU资源时, 往往是在对大表做全表扫描。找出问题SQL的办法如下:先执行onstat-g act得到当前正在运行的sqlexec线程, 再根据该线程的地址信息, 利用onstat-u得到其session信息, 最后根据onstat-g sql得到当前正在执行的SQL。具体示例如下 (为方便阅读, 输出略有改动, 增加了含义行, 删除了无关信息) :

以上两种信息都是即时信息, 最好多执行几次。初步确认问题SQL后, 如果是条件查询SQL, 如带WHERE条件的SE-LECT/UPDATE/DELETE, 还可以通过得到具体的SQL查询计划来确认是在进行全表扫描。对比dbschema得到的建表脚本, 看是否建立了相应的索引, 如果没有合适的索引, 应该创建;如果应用没有合理利用已有索引, 需要修改应用SQL。如果表上有合适的索引, 应用SQL也没有问题, 那么就有可能是由于表中数据已经变化较大而长时间未对表收集统计信息, 造成数据库引擎选择了错误的查询计划。此时通过运行update statistics for table, 针对该表收集统计信息后, 通常可以收到良好的效果。及时删除表中不必要的数据也有助于减少性能问题的发生。有时候问题SQL还会是INSERT语句, 此时需要查看表的建表脚本, 看是否表上有过多的索引, 是否有不适当的外键指向另一个大表, 也可以通过适当删除表中的记录来实现优化。

(2) 数据库应用突然变慢, 查看系统信息, 发现CPU空闲突然很低, IO性能明显恶化。Vmstat显示b (block) 很大, 有很多等待IO的进程, sar显示wio明显超过平时值。观察数据库日志, 发现数据库检查点持续时间显著增加, 平时在3s以内就能完成, 此时需要10s左右才能完成。和问题1的显著不同在于, 此时IO恶化现象非常突然。这种情况最常出现在硬件出了问题时, 比如有磁盘IO错误, 阵列电池没电, 阵列cache没有打开等等。在这种情况下, 单纯修改数据库参数不会有任何意义。

首先还是查看数据库日志和操作系统日志, 排除数据库内部错误和操作系统IO错误。如果用的是阵列 (RAID) , 最好再查看一下阵列的日志。

排除了操作系统和数据库内部错误, 就需要了解一下是否有新的应用在进行大批量的数据操作, 如INSERT/DELETE/UPDATE, 是否能将这些操作放在系统相对空闲的时候进行。对于大批量的数据导入操作, 在INFORMIX9.4中提供了RAW类型的表, 由于不记录逻辑日志, 插入速度会快很多。导入完成后, 再将表修改为正常模式;对普通表应该先导入数据, 再创建索引。注意主键、外键默认都会创建索引, 应该在数据导入后再创建。不恰当地应用SQL也会导致IO量非常大, 可以用案例1中的办法来找到问题SQL, 根据实际情况进行处理。

(3) 数据库稳定运行一段时间后, 性能开始下降, 检查点持续时间开始逐渐增加, 系统CPU空闲降低, WIO有所增加。这些情况最常出现在新的应用上线后一段时间, 当数据量的增长到了一定程度后, 性能问题就会逐步出现。

针对这种情况, 需要确认定期对数据库, 尤其是对数据库中的大表, 定期做收集统计数据的工作 (update statistics) , 避免数据量的增大造成系统性能急剧下降。

找到被顺序扫描多次的大表, 减少其上的顺序扫描。通过onstat-p可以得到数据库自上次启动以来发生顺序扫描的次数, 对小表的顺序扫描不会影响性能, 对大表的顺序扫描就会有严重影响。可以通过下列SQL在应用库中执行得到前5个候选问题表:

SQL根据顺序扫描数、表中记录数 (最好最近收集过统计信息) 、行字节数来综合考虑选择代价最大的表。

得到表名后, 可以通过查找应用的源代码来得到对该表的访问SQL;也可以通过收集多次onstat-g sql 0的结果, 找到该表比较常用的问题SQL;

在Informix9版本之后, 还可以用onstat-g stm来得到应用中编译过的SQL, 通过收集多次onstat-g stm的结果, 也可以找到该表比较常用的问题SQL;

针对这些有问题的SQL进行分析, 采取相应办法:创建相应索引;修改应用SQL;及时删除表中不必要的数据。

以上办法不需要修改数据库参数, 不需要重新启动数据库。如果采取了以上办法, 仍然不能达到期望性能, 就有必要调整数据库参数, 甚至对数据库文件进行IO分布。

检查点持续时间一般不超过3s时, 就认为性能比较理想。在Informix 11之前, 作检查点时, 应用无法执行写操作, 因此较长的持续时间会对应用有较大影响。数据库方面, 通过适当增加LRUS/CLEANERS, 降低LRU_MAX_DIRTY, LRU_MIN_DIRTY及其间隔, 最低可以为2/1甚至1/0, 会减少检查点持续时间。此时更多的脏页在超过了LRU_MAX_DIRTY限制后, 会被刷新到了磁盘, 这样就减少了检查点时需要刷新的页, 减少工作量, 提高了速度。

数据库的IO情况也会影响系统性能。可以通过监控onstat-g ioq的方式, 查看其输出项中AIO/GFD行的请求队列长度 (LEN) 和及其最大长度 (MAXLEN) , 如果LEN总超过10, 而且MAXLEN超过25说明请求没有得到及时处理, 如果磁盘或IO控制器尚未饱和, 则可以通过增加AIO VP (NUMAIOVPS) 的数量来改善, 一般一个chunk分配2个AIO VP是比较理想的。

典型数据 篇8

关键词：程控,交换机,中继,局数据

NGL04交换机是珠海高凌信息科技有限公司研制的面向下一代网络 (NGN) 的多业务局用程控交换机, 自问世以来受到广大用户的好评[1]。由于该交换机是大型局用交换机, 局数据较为复杂, 在日常值班执勤过程中, 往往会遇到局数据方面的故障, 要求工作人员结合实际情况分析处理。现以几个典型故障为例说明。

1 A局用户反映到B局的电话比较难打

故障现象:A局对B局开ISUP电路后, B局发现回的还是TUP信令, A局用户反映到B局的电话比较难打。

故障分析:A局对B局增开ISUP电路, A局数据制作完成并加载后, 电路显示空闲, 但拨打电话测试发现电路占上后释放异常, 并且该电路显示为电路复原等证实状态, 原因初步判断为数据制作方面的问题。

解决方法:和B局沟通后, 由B局进行信令观察, 结果发现, 本局向开的是ISUP电路, 但是A局发送过去的却是TUP信令, 有了这个观察结果, 问题就比较容易处理了。因为在局向电路中定义信令方式的只有“出入局局向特征”[2]数据和“局向电路群”[2]数据, 由此对这两项电路数据进行检查。经查, 出入局局向数据无问题, 信令方式采用的中国七号ISUP电路, 但是发现局向电路群描述中电路类型为公共信令而不是ISDN, 修改后正常。

在处理类似信令问题的时候, 信令观察是一个首先要使用的技能, 通过观察, 从电路上发送接收的消息内容, 能够处理大多数类似的问题。该操作的方法是:首先指定一个拨号的话机, 获得该话机号码。在“指定电路操作”中执行“跟踪用户状态”[3], 在号码输入框输入上述号码。在“指定电路操作”中, 执行“指定观察”[3], 不须输入任何内容, 直接点击确定。通过这种操作, 这个电话发起的任何呼叫, 在指定观察的消息框中都能够看到消息内容。

2 某支局反映用户号码经常丢失

故障现象:某支局反映个别用户号码经常丢失。

故障分析:造成该故障的原因主要有2个方面。一是计算机数据库问题 (病毒或是数据库本身的原因) ;二是交换机本身问题 (主要怀疑SMMP切换时现场没有完全恢复) 。

解决方法:针对第一个方面可以通过查操作报告证实;对于第二个方面看故障出现时是否进行了数据加载;或者用户为空号时局数据中此用户数据是否存在进行判断。根据以上方法, 发现都是在加载了数据以后出现的问题, 用此初步判断该计算机的数据库有问题, 将该计算机上的数据库卸载了重新安装, 设置数据库和ODBC以及局数据以后, 加载正常, 该现象也再未出现。

3 集中方对某个被控局的局数据不能正常连接

故障现象:某支局局数据不能正常连接。

故障分析:在网管中心不能进入某支局的局数据, 影响此业务的正常使用。有可能是支局服务器故障, SQL数据库损坏或未启动, 需重设ODBC数据源等等。现场观测服务器运转正常, 在本地台上启动局数据也不能正常使用。

解决方法:检查SQL数据库是否正常运行, 发现SQL数据库未开启。打开此属性观测到开机重启时未设置成自动启动, 导致计算机掉电重启后, SQL数据库未自动运行。将SQL数据库启动并将其属性设置为开机自动运行后, 重新进入局数据界面, 故障解决。将计算机重新启动, 检测是否排除故障, 观测到SQL数据库已经能正常运行, 且各项业务使用正常。

4 创建加载数据后用户数据又恢复到4天前的状态

故障现象:创建加载数据后, 用户数据又恢复到4天前的状态。

故障分析:初步分析该问题涉及的相关点为:用户数据错误, 创建数据过程未完成, 创建数据产生错误。

该问题是一个较为常见的问题, 简单说, 就是加载到交换机里的数据, 和在局数据界面看到的数据内容, 不是一回事, 所以会出现修改了数据, 但是没起作用的现象。此类问题除了本例中的数据库问题以外, 经常出现的是ODBC数据源指错数据库名的问题。由于服务器软件的缘故, 在服务器端必须存在一个名为“HJD”的数据源。指向本局使用的数据库, 才能保证数据库中的内容能够被正常创建。

5 局数据不可加载

故障现象:某局的服务器突然断电, 重新加电后, 发现服务器界面已丢失, 需重新设置。重新设置后, 进入服务器主界面。重新创建数据文件, 当对交换机加载新数据时, 加载界面一直处在加载的界面, 延续10多分钟, 数据加载不进去;当对单个模块进行加载时, 也出现相同的情况。

故障分析:首先判断是否为交换机的AXME故障, 因所有的交换模块均为如此, 故可以排除AXME的原因。跟踪服务器的主界面, 可看到所有模块均与服务器相连, 故可排除从服务器到达交换机的硬件路径的原因。此时, 可把思路放到软件上。重新生成数据文件, 在C:NDSCRUN目录中, 存在两个文件, 一个指明服务器的操作界面是如何配置的, 另一个是指明数据加载文件加载到交换机的路径 (LOAD, INI) 检查是否正确。经过上述分析, 故障基本定位在是否存在LOAD, INI以及该文件是否正确。

解决方法:经查看C:NDSCRUN目录, 发现该文件已不存在。拷入该文件, 并重新启动服务器, 进行加载新数据的操作, 加载正常。

6 结语

NGL04交换机是大型局用交换机, 局数据较为复杂, 常常会遇到局数据方面的故障。以上列举了5个NGL04交换机局数据方面的典型故障案例并进行了深入分析。网管工作人员要举一反三, 结合实际情况分析处理这类故障。

参考文献

[1]林峰, 孙立炜, 付益兵.基于VFP9.0的NGL04交换机辅助计费系统的设计与实现[J].办公自动化, 2013, 8:16-18.