dba算法

⑴ dba面试会考数据结构与算法和操作系统，计算机组成原理这些大学必修的课程吗

数据结构与算法是必须的，后面的两样在你以后从事工作时会很有用的，因为作为一个dba 你要会开发，还要懂得硬件和存储，而硬件和存储的学习是需要操作系统，计算机组成原理 这两门课程的。
附上dba 面试题：
http://space.itpub.net/22664653/viewspace-628264
http://space.itpub.net/?uid-22664653-action-viewspace-itemid-628265
http://space.itpub.net/?uid-22664653-action-viewspace-itemid-628267
同时也建议你去itpub 论坛去学习，一个挺不错的论坛。

⑵ DB2 DBA,如何解释DB2的业务价值

但是，如果谈话的对方是管理层的成员，那么会怎么样?公司管理者们关心的主要问题是收入的增长、成本控制、产品质量和产品投入市场的时间。一般来说，这些人并不关心锁的粒度、服务器内存管理和 sql 语句优化这样的技术问题。他们并不关心 DB2 技术本身的特色(尽管 DB2 技术是很酷的)，而是关心 DB2 对于实现组织目标能够有哪些作用。本文将帮助使用 DB2 的人从业务价值的角度讨论 DB2 技术。 许多技术人员可以轻松地讨论 DB2 技术的细节，很自信地谈论查询并行化、数据压缩、WebSphere MQ 集成、大对象管理、JDBC 和 ADO.Net 驱动程序、大型机 Parallel Sysplex 上的数据共享、DB2 for Linux, Unix, and Windows(LUW)多维集群等等话题。但是，如果谈话的对方是管理层的成员，那么会怎么样?公司管理者们关心的主要问题是收入的增长、成本控制、产品质量和产品投入市场的时间。一般来说，这些人并不关心锁的粒度、服务器内存管理和 SQL 语句优化这样的技术问题。他们并不关心 DB2 技术本身的特色(尽管 DB2 技术是很酷的)，而是关心 DB2 对于实现组织目标能够有哪些作用。日常使用 DB2 的任何人都应该能够从业务价值的角度讨论 DB2 技术。 通过我在 CheckFree Corp. 的经验，我总结出了一个关键领域列表，在这些领域中 DB2 技术可以提供业务人员能够感受到的价值。 可伸缩性 vs. 随着业务增长 单服务器 DB2 系统(无论是运行在大型机上，还是运行在高端 Linux、Unix 或 Windows 服务器上)可以为 OLTP、业务智能(BI)或组合工作负载提供巨大的吞吐量。吞吐量大主要是由于 DB2 利用了 64 位服务器内存寻址、新颖的 I/O 优化特性(比如列表预获取)、预优化的 SQL(DB2 专业人员将其称为静态 SQL)以及高级工作负载管理功能。但是，在扩张迅速的业务环境中，数据访问请求量会快速增长，单服务器系统的能力可能不足以处理未来的请求量。业务领导肯定不希望业务的增长受到数据服务器可伸缩性的限制。这就是规模扩展(scale-out)的重要之处，而可伸缩性正是 DB2 真正占据优势的领域。 在这个上下文中，“规模扩展” 这个词指的是能够将针对单一逻辑映像数据库的工作负载分散到多个物理服务器上。有两个 DB2 规模扩展解决方案：大型机集群(称为 Parallel Sysplex)上的数据共享和在 Linux、Unix 或 Windows 服务器集群上实现的 Data Partitioning Feature(DPF)。这两种技术都是在行业中领先的技术。DB2 for z/OS 数据共享能够支持企业从最多 32 个 DB2 子系统对一个共享数据库进行并发读/写访问(这些子系统可以运行在许多大型机系统上，也可以运行在少量物理服务器上，每个服务器上有多个 DB2 子系统)。这个解决方案不是市场上惟一的共享数据 DBMS 规模扩展解决方案，但是其他任何技术都无法提供 DB2 for z/OS 数据共享组这样好的 CPU 效率(真正并发的节点间读/写数据访问的 CPU 开销非常低)。 带DPF 功能的 DB2 能够在 Linux、Unix 或 Windows 环境中提供无以伦比的规模扩展能力。可以在一个 DB2 DPF 系统中配置数以百计的服务器;每个服务器提供对单一逻辑映像数据库的一个物理子集的访问(一个散列算法将给定的数据库表的行分散到 DBA 指定的节点上)。市场上也有其他的非共享(shared-nothing) DBMS 规模扩展解决方案，但是其他解决方案都无法像带 DPF 功能的 DB2 那样兼具易用性和灵活性，因为 DPF 功能是嵌入在 DB2 for LUW 数据服务引擎中的。 对于共享数据和非共享 DBMS 体系结构孰优孰劣的问题，人们还在争论;但是，这两种 DB2 解决方案对于底层服务器平台都是非常合适的。DB2 for z/OS 数据共享的 CPU 开销非常低，这是因为它使用的函数以优化的方式分散在整个 Parallel Sysplex 软件结构中：z/OS 操作系统、DB2 DBMS、Coupling Facility Control Code(它管理全局锁和数据缓冲所用的共享内存结构)以及 CICS 事务管理器或 DB2 Connect 分布式客户机网关(如果配置中有这些组件的话)。这种优化是可行的，因为 DB2 for z/OS 数据共享只需要使用一个操作系统和一个芯片组(IBM System z 微处理器)。在 DB2 for LUW 环境中不可能进行这样的功能分布，因为这样的环境需要支持多个操作系统和多个服务器硬件平台;因此，DB2 for LUW 规模扩展解决方案基于最佳的非共享集群技术。无论采用哪种方式，组织都会得到所希望的效果：DBMS 不会阻碍业务的增长。 效率vs. 降低总体拥有成本 在评估各种数据服务解决方案的相关费用时，人们往往关注获得硬件和软件许可证的费用。软件和硬件的价格固然重要，但是在与 DBMS 相关的总拥有成本(TCO)中这只占很少的一部分。影响成本的其他因素包括： 管理数据库系统所需的人数; 使用硬件资源(CPU 和硬盘存储)的效率; 技术的培训费用; 让企业中的不同数据库系统一起工作的难度; 先说说 DB2 for z/OS，因为某些范围内它可以替代非常昂贵的基于大型机的解决方案。下面一些因素可以影响 System z 平台上的成本控制： 规模经济 在DB2 for z/OS 系统上，可以处理非常大的工作负载;即使一连几小时处于 90% 以上的利用率，数据服务大型机也能够顺利地运行。随着事务处理量的增长，平台的单个事务成本会显着降低。 性价比趋势 尽管System z 平台是一种相当昂贵的系统(因为它提供了尖端的硬件和软件技术)，但是在过去几年中，单位计算能力(通常用每秒百万指令数或 MIPS 来衡量)的成本已经下降了。无论是来自 IBM 还是其他厂商的大型机软件，其价格也比以前更有竞争力了。 可管理性 组织可以在大型机 DB2 系统上处理非常大的工作负载，而不需要大量的支持人员。DB2 for z/OS 系统程序员和 DBA 具有令人吃惊的生产效率的原因之一是，许多公司提供了丰富的大型机 DB2 工具;与之相关的另一个好处是，DB2 for z/OS 会产生丰富的跟踪数据，前面提到的工具可以对这些数据进行格式化，而且成本往往非常低。DB2 for z/OS 支持人员还可以获益于某些平台特性，比如系统管理的存储，这个特性能够让 z/OS 操作系统在硬盘子系统中放置表和索引数据集(数据库越大，系统管理的存储的人员效率优势就越显着)。 数据存储的空间效率高 DB2 for z/OS 服务器硬件可以帮助进行数据压缩，这可以将表空间存储的硬盘空间需求降低 50%以上(我们在 CheckFree 常常观察到 70% 或更好的压缩效果，因为我们的表往往具有很长的行;长行的压缩率一般好于短行)。由于 DB2 9 中的改进，在 Linux、Unix 和 Windows 服务器上数据压缩效果也很好了。 自治是什么意思?这个词是指 DB2 能够自行完成以前需要 DBA 执行的大量工作。我们在 CheckFree 发现，通过使用 DB2 Design Advisor(DB2 for LUW 中内置的自治特性之一)，效率得到了极大提高。Design Advisor 会分析与 DB2 工作负载相关联的 SQL 语句，并为改进应用程序性能提出建议。我们的基于 AIX 的企业数据仓库(EDW)使用带 DPF 功能的 DB2，Design Advisor 对这个数据库提出了修改某些表索引的建议，其效果让我们非常满意。 最后，还有协作方面的好处。CheckFree 的 IT 基础设施有意地设计成包含多个平台(我们常常说的一句话是，“使用正确的工具完成工作”)。在我们最大的部门中，核心业务应用程序运行在一个大型机 parallel sysplex 上。这个部门的操作数据存储(ODS)运行在一个单独的 System z 服务器上。我们的 EDW 运行在 IBM pSeries 服务器集群上，CRM 应用程序运行在一个单独的 Sun Solaris 服务器上。这些系统有什么共同点?它们都是基于 DB2 的。DBMS 具有共同的 “基因”，这会简化平台之间的数据转移，并增强人员配置的灵活性。最近，我们的大型机 DB2 团队中 DBA 人员过剩(尽管这些系统已经增长了，这是一种便于管理的环境)，而快速增长的 EDW 需要更多的 DBA 人力资源。我们让一位 DB2 for z/OS DBA 转入了 DB2 for LUW 团队，他很快就适应了新的岗位。DB2 for z/OS 和 DB2 for LUW 之间存在 DBA 能够察觉到的差异吗?确实有差异，但是与 DB2 for z/OS 和在分布式系统服务器上运行的非 DB2 DBMS 之间的差异相比，这些差异是很小的。 高可用性 vs. 拿起电话话筒就能听到拨号音 在CheckFree，我们一直在为应用程序的可用性而努力。我们希望应用程序的可用性像电话拨号音那样持续不断，当您拿起电话话筒时，就一定会听到拨号音。DB2 能够提供这样的可用性。单服务器 DB2 系统已经能够提供极其出色的可用性;多服务器配置甚至能够进一步提高可用性标准。 前面作为规模扩展解决方案提到了 parallel sysplex 上的 DB2 for z/OS 数据共享，这种技术也能够在两个方面提高可用性： 减小服务意外中断的影响 如果数据共享组中的一个 DB2 子系统失败了(无论是由于服务器、操作系统还是 DB2 故障)，那么并不需要等待替代服务器接管这个子系统的数据库连接。组中的其他成员已经能够访问数据库，工作负载会自动地从失败的子系统转移到其他 DB2 系统上。失败并非毫无影响，因为在失败的 DB2 子系统重新启动之前，这个成员上运行的程序正在更新的数据库页面是不可访问的;但是，在通常情况下，处于这种状态的数据库页面所占的百分比非常小，子系统的恢复是自动的(如果 “主” 服务器和操作系统仍然可用，那么会 “就地” 恢复;否则，在 sysplex 中的另一个服务器上恢复)而且很快(在我们的环境中大约需要 90 秒)。与单独的系统环境相比，数据共享组中的 DB2 失败的影响要小得多。几个月前，我们的生产数据共享组中发生了一次 DB2 for z/OS 故障，但是客户都没有察觉到。 几乎完全消除有计划的服务中断 因为数据共享为所有 DB2 成员提供对数据库中所有数据的读/写访问，所以可以让一个 DB2 子系统临时停止运行，对它进行软件维护，然后让它重新运行，这个过程不会中断应用程序的处理(当一个 DB2 成员停止运行时，应用程序通信量会转给组中的其他成员)。这种功能让我们能够自由地对数据共享组进行维护，而不需要指定维护时间窗。 DB2 对于业务的意义 如果需要用业务人员能够理解的方式讨论 DB2，那么可以试试下面这些词汇。 可伸缩性：DB2 可以随着业务而增长，而不是限制业务的发展; 效率：DB2 可以降低数据服务平台的总拥有成本(TCO)，而数据服务平台是组织的应用程序的基础。降低 TCO 就相当于增加收入; 服务质量：DB2 技术可以减少有计划的应用程序系统中断，还可以缩小意外服务中断的影响和范围。因此，能够提高服务质量和客户忠诚度; 敏捷性：DB2 为访问和管理传统数据和非结构化数据提供了众多可选方法;这种灵活性可以帮助组织对市场机遇做出快速响应。 对于LUW 环境，DB2 提供了一个多服务器解决方案，这个方案能够提供更高的可用性，但它使用的是在非大型机环境中更有意义的非共享体系结构。这个解决方案称为 High Availability Disaster Recovery(HADR)，它可以维护 DB2 for LUW 数据库的一个拷贝(使用单独的服务器和硬盘存储)，这个拷贝与主数据库保持精确的同步。HADR 的实现方法是，不断地将事务日志记录发送给备用服务器，备用服务器实时地处理这些记录。这种方法会让备用数据库与主数据库同步，而且更新过的页面的内存页面缓冲区也与主服务器上的缓冲区保持一致。因此，在主系统发生故障时，备用系统会非常快速地接管(通常只需要几秒)，而且不会丢失已经提交的数据库更新。HADR 还可以按照异步模式运行，这种模式适合长距离数据更新复制，在可以接受少量数据损失的情况下，这可以提供灾难恢复功能。 HADR 也可以减少有计划的服务中断时间，因为它使 DB2 for LUW 的维护几乎不需要维护时间窗。为使用 HADR 实现这种效果，DBA 应该临时终止从主服务器到备用服务器的日志记录流，在备用服务器上应用并激活软件补丁，重新启动日志的传输，恢复同步(这个 “追赶期” 通常非常短);然后，通过一次用户发起的接管，交换主服务器和备用服务器的角色(这个过程应该只需要花几秒时间)。在此之后，重复前面的步骤，在 HADR 配置中原来的主服务器(现在的备用服务器)上应用并激活软件补丁。 敏捷性 vs. 对新的需求做出快速响应 DB2 能够帮助组织对挑战和机遇做出快速响应，因为它能够提供多个访问 DB2 数据库中的数据的路径。您希望从 java 应用程序访问数据吗?没问题：DB2 提供了 JDBC 驱动程序并支持 SQLJ，因此能够在 Java 应用程序中使用嵌入的预绑定的 SQL 语句。数据请求来自 Windows 系统上运行的 .Net 应用服务器吗?DB2 提供了 ADO.Net 驱动程序，并与 Microsoft 的 Visual Studio 应用程序开发工具集成。您希望使用服务器端 SQL 吗?DB2 存储过程可以用几种编程语言来编写(包括 Java)，也可以采用 SQL 存储过程的形式。在大型机环境中广泛使用的 CICS 和 IMS Transaction Manager 程序可以提供更多的服务器端 SQL 方式。对于文件处理这样的任务，批处理程序具有很高的效率。 通过DB2 与 IBM WebSphere MQ(一种消息排队和传递技术)的集成，应用程序开发的灵活性会得到进一步增强。将 MQ 插入基于 DB2 的基础结构中是一种增强系统弹性的好方法：如果应用程序的 “处理消息” 的组件不可用(由于故障或有计划的停机)，那么从客户机系统收到的消息就会累积在队列中，当不可用的应用程序组件再次联机时，它会继续从队列中获取消息。从发送消息的用户或客户机应用程序的角度来看，并没有出现服务中断。MQ 队列还有助于控制大幅度变化的工作负载量，其作用就像是汽车引擎散热器的附属水箱：消息处理应用程序可以按照自己的节奏处理消息;如果消息到达的速度超过了处理消息的速度，那么消息就会累积在队列中，而不会造成 “目标” 服务器过载。DB2 和 MQ 组合的优点还包括：协调的提交和回退(如果程序在 DB2 表中插入一行并在 MQ 队列中放一个消息，那么当这个程序失败时，DB2 和 MQ 更改会回退到最近的提交点);DB2 函数支持程序使用 SQL 语句与 MQ 交互;MQ 实用程序与 DB2 实用程序非常相似，因此 DB2/MQ 的交叉培训非常容易。 数据级别上的灵活性怎么样呢?DB2 可以存储和管理传统的文本和数字数据，还可以非常高效地管理大对象(LOB)，比如文档、图像和音频文件。DB2 9 引入了先进的 XML 数据存储特性，在存储 XML 文档时可以保留数据元素的结构特性，还可以使用 SQL 或 XQuery 高效地访问数据。当然，可以在 DBMS 之外存储 LOB 和 XML 文档;但是，将这些数据类型存储在 DB2 中，就可以为集成数据管理、安全性以及备份和恢复提供一个现成的解决方案。其结果是，管理和保护数据所需的时间更少了，可以留出更多的时间来开发使用数据的应用程序。 技术的最终目的 我很喜欢谈论在各个平台上 DB2 中使用的高级技术。但是，技术必须能够帮助我的公司实现业务目标;否则，就是浪费资金。大多数业务人员对 IT 产品的要求只有几点：产品必须能够工作(可靠性)，它们不能限制公司在市场上的作为(增长和创新)。DB2 在 CheckFree 的各个平台和应用环境中表现出了这些品质。业务人员需要的就是这些;技术人员请务必注意这一点。

⑶ 我今年刚毕业，学的软件工程，对数据方向比较感兴趣，但是不知道是做bi好还是做dba好希望达人帮帮小弟。谢

BI和DBA完全是两个方向。我就是软件工程毕业的，当时也是想当然的以为，BI嘛，数据挖掘，不要依托数据库吗？后来干了DBA，毕业设计选的数据挖掘，本来信心满满，后来才知道，坑爹啊，数据挖掘这么复杂。
数据挖掘主要还是数理分析，数学功底要好，特别是高等数学的功底要好。主要实现手段是和数据库没什么关系的工具，比如做分类分析的matlab，关联规则的spss,，聚类分析的weka。唯一和数据库挂钩的是从数据库上把数据export下来。matlab是矩阵实验室，完全靠数学，spss类似excel，基本靠函数，weka是开源的jar包，主要靠编程，但能够实现自己的算法，所以非常牛叉。但是效率你懂得，算法执行海量数据那是相当的慢。
DBA就不同了。首先dba还是要分两个方向的，开发DBA和管理DBA。开发DBA主要负责配合项目组开发，最重要的工作就是sql支持，具体力度就不好说了，有的可能要负责数据库设计，有的只要负责sql审核，不过最主要的工作还是sql性能的优化，需要会使用toad这些工具，最关键的是对数据库优化器、sql甚至磁盘存储都要有一定认识。这类牛人比如阿里巴巴旗下的童家旺、冯大辉。
管理DBA，一般都是大牛，多数DBA都是从开发DBA开始。对oracle体系结构，数据库的安装配置，容灾备份，迁移，rac，dg等等，也是大多数人眼中的DBA。这类牛人主要是盖国强盖神带队的oracle ACE OCM各种大牛，让你仰视N久。
当然以上这些dba都是应用方向，换句话说，必须给你oracle或者mysql，你才能玩得转。但是现在数据库有新的牛人，主要像淘宝和豆瓣这种，自主开发适合自己业务需求的数据库，那才是潜力无限。
最后，dba需要的是经验，bi需要的是学识（也包括学历）。

⑷ 企业国际电子邮件延迟如何解决跨国视频会议丢包如何解决

企业国际电子邮件延迟如何解决？

• 确保邮件队列干净，没有过多的异常邮件。

• 确保本地网络带宽资料充裕，让员工不要集中收发邮件。

• 尽量减少附件的大小。

跨国视频会议丢包如何解决？

丢包严重影响视频会议使用体验，因此人们也找了很多方法来破解丢包难题，主要常见的有三种：丢包恢复、动态带宽分配、视频差错隐消。

丢包恢复(LPR)通过介入到视频通话中的各方系统中去解决丢包问题。LPR通过临时将一部分通话带宽分配给一个数据通道，从而用于发送FEC数据给接收系统来发挥作用。通过一个循环处理，LPR会增加或减少FEC数据通道的大小，直到找到必须分配给FEC数据通道的最小带宽，从而使得接收系统能够恢复所有丢失的数据包。

动态带宽分配（DBA），是针对带宽影响制定的，DBA也是一种算法，通过和LPR合作，在视频通话过程中自动且动态地调整视频码率，以消除或避免丢包。

视频差错隐消主要应用在参与通话的各方系统都不支持LGOOGLE PR的情况下。PVEC是一种用于IP视频服务质量QoS）的算法。它可以对由丢包所造成的影响进行补偿。它通过利用相邻的宏块、前帧和后帧来估算出当前视频帧的网站内容。与LPR的恢复丢失的数据包和DBA的避免丢包技术不同，PVEC的作用是掩盖丢包造成的影响。

云际视界云视频会议是目前市面中表现优异、抗丢包能力较强的视频会议产品。上手快，操作方便，”新手”企业也能快速上手使用，进行企业各种会议。

希望小云的回答对您有帮助~

⑸ 如何实现高清视频会议

1、首先，摄像头必须得清晰，要实现高清视频会议，最起码得选择720p及以上的摄像头，当然了肉眼上看，720p的清晰度跟1080p的差不多，价格却差得 比较远，所以一般从预算节省方面考虑720p的摄像头即可。目前市场上720p的摄像头做得比较简单易用，稳定。
2、网络必须得给力。RHUB连通宝高清视频发布之前，原来开高清视频会议，最起码也得点对点专线，现在不同了，500多kbps左右也可以开高清视频会议 了，很多企业实际使用的时候，虽然自己是几十M的光纤，但是由于没有使用上网管理行为软件，所以导致公司网络分布不均，所以建议通过上网管理行为软件，限 制开高清视频会议的电脑带宽不低于500kbps，这样才可以避免卡，马赛克的问题。
3、高清视频会议系统必须得选合适的。如过使用网络环境是专线几M,那么所有能买断独 立部署的高清视频会议系统都是可以很好的实现高清视频会议的。但是企业开会的地点不定，网络也不一定，这样的网络环境下换想开高清视频会议的话，目前恐怕 也只有RHUB连通宝可以支持了。不过，即使如此，也需要保证最低300kbps才可以达到高清效果，否则是依然能很清楚流畅看到人，只不过无法高清视频 看到毛孔和黑头的720p级别。

⑹ MD5算法：DBA8CF50代表什么数字

md5值必须是32位或16位或18位或40位的值，你这什么都不代表

⑺ 数据库dba工程师有35岁中年危机吗30岁之后再入行数据库dba职位可以吗

基本来不及，数据库这块和编程什么的有一定的共同性，那就是“易懂难精”。
就平时用到的来说可能增删改查就足够了，不过如果是dba那就不一样了。
小一些的简单一些的：表的设计，范式结构设计（其实就是数据范式结构化的意思），查询语句设计。
系统化一些的：展现控制，数据流程，数据调优，系统优化，数据治理等等。
高大上一些的，比如数据库架构，算法设计等等。
现在提倡云计算，可能还要有一些java的变成基础，可能还需要hadoop等等。
如果原来是做实施运维的，那么数据库确实会接触一些，不过内容不会特别深入，但是如果转行做dba那就不一样了。
记得十年前给公司的运维培训的时候，我曾经讲过数据库，不过运维大多兴趣缺缺，因为这些在实际中虽然一直在用，但并不是那么明显，他们不想弄明白为什么要这么调，只要知道怎么调就可以了，而为什么这么调正是dba的工作。
至于有没有35岁危机，答案是有，在国内来说dba和程序员是一样的，如果一个人35岁还是一个程序员，你觉得会不会有危机，肯定有，dba的工作也一样。当然dba稍微好一点就是这个工作真的需要经验，不过按照你的说法，现在入行，确实有点晚了。
不过也可能你十分适合数据库的工作，很快就能完成以上的内容，然后大获成功，马云也是30多岁才创业，不也成功了吗，我的说法只适合一般人，如果你能转行成功，那么只能说明你真的很强。

⑻ pon系统qos控制，采用什么技术

可以通过DBA(动态带宽算法)，DIFFSERV,PQ/WFQ,WRED等来实现对每个用户进行带宽分配，并保证每个用户的QOS.

⑼ 应用简单的匹配算法对主串s=''BDBABDBABDBA''与子串t=''DBA''进行模式匹配，在匹配成功时，进行的字符比

简单的匹配算法

对主串s=''BDBABDBABDBA''与子串t=''DBA''进行模式匹配，

在匹配成功时，进行的字符比较总次数为4次。