組網實例三

公司局域网组建方案: 　　 公司有三栋建筑，在这里，称之为 1 号楼，2 号楼，3 号楼。 　　 一号楼：三层，公司主要的办公楼，销售部，财务部，行政部，服务部等等皆集中 3 楼，但计算机并不多，约有 20 台 PC 机。目前需要连网的仅有 10 台。 　　 二号楼：二层，研发部，有 19 台 PC 和一台 Sun 工作站。全部需要连网。 　　 三号楼：二层，生产部，目前只有1台PC。 　　 任何单位兴建一个网络都是有一定的需求的，要求使用网络能完成一定的工作，在满足应用的前提下，适当留有余量。同样，公司建立网络是为公司管理系统修路。考虑到日后的发展，我们用的是 100M 快速以太网，这年头这玩意最流行。从带宽上看，100M 远远超过了应用的需求。不过谁也不敢保证 3 年后 Microsoft 要求多高的带宽。也没有必要追求高性能而配置 1000M 的网络，因为这样不经济（当时，1000M 网络标准并未确定）。 下图是网络拓扑图： 网络设备选型 　　不同的网络设备的价格相差甚大，首先让我们来简单了解一下网络设备。 HUB ：也就是所谓的集线器，它又可分为好几种，有普通 HUB，堆式 HUB，端口交换式 HUB 等等。100M 的 HUB 的带宽是共享的，也就是说，24口 的 HUB 的 24 口共享 100M 带宽，如果 24 口同时传数据，那么每个口的带宽就只有大约 10M。堆式 HUB 是一种可以堆叠的 HUB，也就是说，如果我们需要将 48 台机器联网，我们可以用 2 台堆式 HUB 堆叠起来当作一个 48 口的 HUB。 交换机 ：可以认为是一种高性能的 HUB，它的 100M 带宽是独立的，或者说它允许几个端口同时以 100M 的速度传递数据。交换机通常还带有路由功能。 　　 网络中心是公司网络的核心，为避免可能的网络上的碰撞，我们的核心设备选用的是 Bay 公司的 350T 型交换机，它自适应 10/100M 网络，带有路由功能，总体性能不错。所有的 HUB 都直接与交换机相连，重要的服务器也直接接在交换机上，这样可以充分发挥交换机速度快，带宽高的优点。 　　 我们选用的 HUB 是 Intel 公司的 Express 100TX-BASE 堆式 HUB (Intel 可不甘于仅仅只做 CPU，它还做网卡、显卡，说不定哪天它会做机箱呢。:-），它有 24 个口，可堆叠使用。使用 Bay 公司的技术制造，性价比不错。 　　 注意：该 HUB 的第 1 个口的左边有一个小按键，按下它则第 1 口的 1、2 与 3、6 交叉，该口就是专用于 HUB 与 HUB 或交换机相联的一个端口。事实上，我公司的堆式 HUB 就是这样与交换机相连的。 网卡 ：每台电脑都需要一块网卡，我们初期选用的是 3Com 公司的 3C905，10/100 自适应网卡，也买过几块 Intel 的 82557，使用一段时间后，有块 Intel 的网卡就坏了，比较而言，3Com 的网卡质量要好过 Intel 的网卡。后来我们使用的是 D-Link 公司的 DFE-500TX 网卡，性价比相当不错。 网络布线系统 ：选用 AMP 公司的五类布线系统。在制作网线时要注意，不是简单的将 RJ-45 的 8 根线一一接通就可以了，必须保证 1、2 双绞，3，6 双绞，4、5 双绞，7、8 双绞，如果仅仅是一一对应接通而不是保证 1、2 双绞，3、6 双绞的话，可能引起网线较长的的站点工作不稳定，甚至无法正常工作。 　　 在我们的网络设计中，我发现了一个难点：从 2 号楼的网络中心到 1 号楼 3 楼的 HUB 处网线长度超过了 110，超出了 5 类线的最大距离 (100 米)。最初我想在两栋楼的中间做一个井，在井里放一台 HUB 作中继，但这样施工麻烦，可靠性难以保证。无意中我了解到了有一种超 5 类电缆，最大带宽可达 345 M，当用于100M系统时，最大距离为 145m，这就正好解决了我们的难题。 　　 下面是我对市面上的两种超五类电缆的测试情况。 距离 (m) AMP Belden 305m no no 170m no 未测 130m OK 未测 146m 未测 OK 160m 不稳定 不稳定 ※ 不稳定：测试是将一个 Hub 与交换机相连时，插在交换机的 5、6、7 口时不通，但第 8 口都通。 　　 从以上结果看，超五类实际指标最大为 150m，超过 150m 将不能正常工作。 网络配置、施工 服务器设置 ：局域网上共 2 台服务器，其中 1 台用做内部文件服务器。另一台用做 Internet 服务器。Internet 服务器运行 Windows NT + IIS + Exchange Server，提供 WWW、FTP、Email 服务。 施工 ：计算网线长度时要注意预留 10% 的余量，避免万一由于建筑物的结构原因必须的绕道和其他难以预料的情况。 　　 一个综合布线系统与其说是计算机工程不如说是建筑工程，实际的性能与安装工艺有很大关系，施工时要注意网线不能承受曲率过大的弯曲，避免靠近强干扰源，建筑物子系统（也就是连接两栋建筑物的网线）必须加强保护，我们对这部分网线采用的是走钢管，这样做的好处是：强度高、抗干扰能力强。 IP 地址分配 ：根据 RFC1597 的有关规定，为便于以后方便与 Internet 相连及考虑到公司的发展，决定在公司内部使用 B 类网络，网络号为 172.16，对应的子网掩码为 255.255.0.0。 服务器：rd 172.16.0.1~172.16.0.254 技术部：rd 172.16.1.1~172.16.1.254 销售服务：xf 172.16.2.1~172.16.2.254 质管部：zg 172.16.3.1~172.16.3.254 采购部：cg 172.16.4.1~172.16.4.254 财务部：cw 172.16.5.1~172.16.5.254 行政部：xz 172.16.6.1~172.16.6.254 后勤部：hq 172.16.7.1~172.16.7.254 生产部：sc 172.16.8.1~172.16.8.254 　　计算机名取名规则：部门代码 + 序号，IP 地址尾数与计算机名尾数一致。例如，172.16.1.1 ==> 技术部 rd1。 　　 以上是我公司的 IP 和计算机名的设置规则，仅供参考。 理解 IP 地址和子网掩码 　　 在这里我不由得想罗嗦一下子网掩码： 　　 我们知道，IP 地址是一个点分十进制数，每个 IP 地址由两个部分组成：网络号和主机号。网络号标志一个物理的网络，同一网络上的所有主机需要同一个网络号，且该网络号在 Internet 上是唯一确定的。主机号确定网络中的一个工作站、服务器、路由器等 TCP/IP 主机，对于同一网络来说，主机号是唯一的。通过网络号 + 主机号，我们可以在 Internet 上确定一台主机的位置。 　　 既然网络号 + 主机号就可以确定一台主机，那么子网掩码有什么用呢？ 　　 Internet 为了适应不同大小的网络，定义了 5 种 IP 地址类型： A 类地址：最高位为 0，紧跟的 7 位表示网络号，剩下 24 位表示主机号，总共允许 126 个网络，每个网络约 1700 万台主机。 B 类地址：最高 2位为 10，其后 14 位为网络号，剩下 16 位为主机号，它允许 16384 个网络，每个网络约 65000 台主机。 C 类地址：最高 3位为 110，紧跟的 21 位为网络号，剩下 8 位为主机号，它允许 200 万个网络，每个网络约 254 台主机。 D 类地址：高 4 位为 1110，用于多路广播。 E 类地址：高 4 为 1111，仅供试验，为将来的应用保留。 　　如果你是一个 A 类网络的管理员，你一定会为管理数量庞大的主机头痛，如此为了方便管理，就需要根据实际情况将其分割为许多小子网，如何分割呢？这就需要用到子网掩码。 　　 子网掩码是一个 32 位地址，用以区分网络号和主机号，这样 TCP/IP 就可以一个 IP 地址究竟是本地网络还是远端网络。 　　 TCP/IP 网络上的每一台主机都需要一个子网屏蔽，如果网络尚未划分子网，则应使用缺省的子网掩码，当网络划分为子网后，就应使用自定义子网屏蔽。 　　 TCP/IP 初始化时，主机的 IP 与子网掩码相“与”得到一个数 M。当需要发送数据时，TCP/IP 协议使用子网掩码与目的 IP 相“与”，得到一个数 D。当 M 和 D 相等时，TCP/IP 协议认为该数据包属于本地网络，反之，如果不等，则数据包被送到IP路由器上。 　　 如：一台主机的 IP 为 192.0.2.1，子网掩码为：255.255.255.0，则 M=192.0.2.0，如果它发送数据包给 192.0.2.114，则 D=192.0.2.0，M=D，TCP/IP则知道 192.0.2.114 在本地网络。如果发送数据给 193.0.2.1，则 D=193.0.2.0，M 与 D 不等，则该数据包送到路由器上。 　　 缺省子网掩码：对应的网络号的位都置 1，主机号都置 0。如： 　　 * A 类网络缺省子网掩码：255.0.0.0 　　 * B 类网络缺省子网掩码：255.255.0.0 　　 * C 类网络缺省子网掩码：255.255.255.0 　　 自定义子网掩码：将一个网络划分为几个子网，需要每一段使用不同的网络号或子网号，实际上我们可以认为是将主机号分为两个部分：子网号、子网主机号。 　　 通过划分子网，你可以混合使用多种技术，克服当前技术上的限制，最重要的是减少广播式传输，减轻网络的拥挤。 如何定义子网掩码？ 　　 在动手划分之前，分析一下你目前的需求和将来的需求计划，重要从以下方面考虑： 　　 1． 网络中物理段的数量 　　 2． 每个物理段的主机的数量 　　 第一步：确定物理网段的数量，并将其转换为二进制数。 　　 第二步：计算物理网络的二进制位数。例如：你需要 6 个子网，6 的二进制值为 110，共3位。 　　 第三步：以高位顺序将所需的位数转换为十进制。如果你需要 6 个子网，6 的二进制值为 110，共 3 位，因此将将主机号的前三位作子网号。11100000 的值为 224，对于 A 类网络则子网掩码为：255.224.0.0，对于 B 类网络则子网掩码为 255.255.224.0，对于 C 类网络则子网掩码为：255.255.255.224。

相关文章：

1、大型网吧网络系统设计详细方案 　2、win2000共享上网 　3、windowsXP共享上网

posted @ 2006-04-11 13:48 青蛙學堂 阅读(595) | 评论 (0) | 编辑 收藏

組網實例二

对于五百台以上机器的网吧，网络质量的好坏，直接决定了网吧的生存能力。如何规划一个优质的网络环境，是我们一些网管们面临的一次挑战。C类的IP地址决定了一个网段只能容纳253台机器，因此，随之而来的各种问题也就出现了。 　　 大型网吧是一个多元化应用的系统集成网络，具备较强的预扩展性。越来越多的大型网吧正在或者已经建立多元化的网络。 　　 一、需求分析 　　 大型网吧网络系统建设的主要目标是建设成为主干跑千兆，百兆交换到桌面；同时在大型网吧的范围内建立一个以网络技术、计算机技术与现代信息技术为支撑的娱乐、管理平台，将现行以游戏网为主的活动发展到多功能娱乐这个平台上来，籍以大幅度提高网吧竞争和盈利能力，建设成一流的高档网吧，为吸引高端消费群打下强有力的基础。 　　 按照这一目标，大型网吧网络系统的主要目标和任务是： 　 1、 在大型网吧管辖范围内，采用标准网络协议，结合应用需求，建立大型网吧内联网，并通过中国电信宽带网与Internet相连； 　 2、 在大型网吧内联网上建立支持娱乐活动的服务器群（包括WWW、FTP、DNS、流媒体服务器、十六频道有线电视转播服务器组及SF和各种游戏战网服务器等），具有信息共享、传递迅速、使用方便、高效率等特点的处理系统； 　 3、 视市场环境允许，向中、小型网吧及网络固定客户提供服务器群资源有偿共享服务，在小范围内尝试为小私营企业主提供一体化网站解决方案（空间、域名、网站、数据库及更新等）； 　 4、系统应有高可靠性、安全性、可维护性和可扩充性，要具有良好的用户界面。 在本方案的设计过程中，始终以大型网吧建网的实际需求为主要参考，在较充分地了解大型网吧应用需求的基础上，根据网络建设中的相关技术路线和建设方针，最终完成了下面的方案设计。 　　 二、网络设计原则： 大型网吧网络系统建设是一项大型网络工程，各网吧需要根据自身的实际情况来制定网络设计原则。在大型网吧的网络建设过程中，其遵循以下网络设计原则： 　　 1、实用性和经济性 由于网吧一次性资金投入大，设备折旧快，目前外部经营环境差。另一方面，网吧应用环境比较恶劣，顾客应用水平较参差不齐，因此，在网络的建设过程中，系统建设应始终贯彻面向应用，注重实效的方针，坚持实用、经济的原则。 　　 2、先进性和成熟性 当前计算机网络技术发展很快，设备更新淘汰也很快。这就要求网络建设在系统设计时既要采用先进的概念、技术和方法，又要注意结构、设备、工具的相对成熟。只有采用当前符合国际标准的成熟先进的技术和设备，才能确保网络络能够适应将来网络技术发展的需要，保证在未来几年内占主导地位。 　　 3、可靠性和稳定性 在考虑技术先进性和开放性的同时，还应从系统结构、技术措施、设备性能、系统管理、厂商技术支持及维修能力等方面着手，确保系统运行的可靠性和稳定性，达到最大的平均无故障时间。 　　 4、安全性和保密性 在系统设计中，既考虑信息资源的充分共享，更要注意信息的保护和隔离，因此系统应分别针对不同的应用和不同的网络通信环境，采取不同的措施，包括系统安全机制、数据存取的权限控制等。 　　 5、可扩展性和易维护性 为了适应系统变化的要求，必须充分考虑以最简便的方法、最低的投资，实现系统的扩展和维护。把当前先进性、未来可扩展性和经济可行性结合起来，保护以往投资，实现较高的总体性能价格比。 　　 三、 网络设备选形 由于网吧的条件千差万别，对方案的要求也五花八门，这就要求网络设备提供商能够具有强大的网络产品和解决方案定制能力；此外，网吧经费有限，因此也不会有很多财力用于网络建设，这就要求网络产品还必须具有极高的性价比优势。在对各网络设备 性能和价格考察比较之后， 大型网吧的网络决定采用：三层中心交换机（加X个千兆模块）+堆叠交换机（加1个千兆模块）作为接入层的网络结构，满足了大型网吧网络对性能、应用、成本等方面的要求。 　　 四、方案拓扑结构： 　　 五、方案说明 　　 1、网络中心设备 中心机房的网络设备选用模块化三层交换机，根据需要灵活地选择不同的扩展模块,实现各种配置组合，在将来进行网络升级时，可通过扩展模块,便于保护现有的网络结构及投资。现根据现有网络的需要， 主干交换机配1个路由模块具有三层交换功能，配5个的千兆光纤模块,配1个10/100M自适应的RJ-45口模块，为了管理方便再配1个管理模块；服务器可选用3—4台多CPU的SCSI磁盘RAID的专业服务器和几十台普通 电脑DIY服务器组成服务器群；路由器可选用模块化路由器作为与Internet的网关和拨入服务器。配备1台用于网络管理的工作站装上网管软件，即可进行网络的配置与管理。 　　 2、二级交换设备 选用千兆堆叠交换机组，由可堆叠交换主机和可堆叠交换从机组成无阻塞星型拓扑堆叠结构，可提供 上百个10/100M自适应RJ-45口（视具体设备而定，网吧这种大流量网络要求以100口左右为一虚拟子网比较稳定）。堆叠方式可提供高Gbps的背板带宽。 　　　 六、方案特点 　　 本方案采用"千兆干线，百兆交换到桌面”的设计思路，各骨干线路均为1000M光纤。所采用的骨干产品都支持802.1Q标准VLAN和IGMP组播协议，全部支持网管到桌面。网络建成后，能很好地满足网吧的各项业务应用需求，达到了预期目的。骨干网通过高速线路接入INTERNET，网吧内实现主干千兆交换、百兆到点，整个 网吧内实现无阻塞通信。其中网络中心可通过划分VLAN，MAC地址绑定来控制不同类别用户的访问权限和浏览站点，网络设备支持IGMP组播与802.1P优先级协议，为VOD、多媒体娱乐等丰富应用的开展打下了坚实的基础 。 　　　 七、随笔 　　 本方案设计过程中的重点在其网络结构和服务器群，使其两者有机配合才能真正充分发挥大网吧的优势，在硬件安装调试结束后经营中的是否成功和服务器群的建设有很大的关系，高薪聘请个一流高技术的真正网管是必须的；以500台的网吧为例，建个30—50台服务器的服务器群，就是每月化上万的代价请个一流网管也不为过，重要的是有效保证你的服务器群上各种平台开发、应用以及网络的正常运转（为了保证网管的开发积极性最好还是用干股分红的方式 使其报酬和网吧经营状况挂钩）。其实这也是目前大型网吧的通病，大多只重视客户机的台数而不注重网吧的内容服务，那只能和中、小网吧进行残酷的价格战，服务器群内容的好坏在一定程度上能左右网吧的价格定位 、竞争环境以及增值服务在网吧总收入中占有的比例；原因很简单，网吧就如同超市，一般中、小网吧 就如新村小卖部，其客户群定位是附近居住小区，一般顾客也是以"就近原则”上网吧消费的；大网吧则有个关键的区别就是上坐率！光靠附近居住小区是难以为继的，必须象大型超市一样有鲜明的消费热点，给顾客充分"舍近就远”的理由，电脑高折旧率的今天大网吧 仅仅靠价格战很难在竞争中占有利地位。。。。 　　　下面这个是对应300台左右规模网吧的拓扑结构 　　　　　　　 300台左右规模网吧的拓扑结构:

*************************************************

posted @ 2006-04-11 13:42 青蛙學堂 阅读(192) | 评论 (0) | 编辑 收藏

組網實例

现有两个局域网网段以及若干未连入局域网的计算机，要求将所有计算机连入局域网。共有用户40台左右，希望有较大的扩展空间。所有计算机都能够随时的、有控制的上Internet。各部门的计算机可以相互共享信息和设备，但不能访问到管理部门的计算机。
应该如何构建？是否需要交换机或路由器？代理服务器如何设置？
以40 到50 台计算机为例，介绍一个典型的组网实例。50 台左右的计算机组成的局域网属于一种小型网络，这种规模的网络目前在学校、培训机构、网吧及一些中小企业较普遍。
1．网络结构的选择采用目前流行的快速以太网技术，使用星型拓扑结构，组建一个可以满足客户机/服务器及对等网要求的小型局域网。
2．硬件的准备组网硬件包括服务器、工作站、网卡、集线器和双绞线等，在选择时需要根据不同的网络应用需求，进行整体的分析和考虑。
服务器：网络的重点设备，在许可的情况下，尽量配置高一些，最好采用专用服务器，避免使用普通高配置计算机充当服务器，原因在于专用服务器是针对网络应用专门设计的，网络性能要比普通计算机好很多。
工作站：选择流行机种，以满足需求的基本配置为度，数量的选择兼顾集线器端口的数量，一般集线器常见端口数为8 口、12 口、16 口和24 口，不要造成太多的端口浪费。
网卡：工作站计算机选择10M/100M 自适应PCI 总线网卡，专用服务器一般都自带一个10M/100M 自适应网卡。
集线器：集线器的选择很大程度取决于组建的局域网的网络工作性质，一种情况为各工作站的网络通信主要是与服务器之间的通信，工作站之间没有什么通信，这种情况可以采用两个24 口可堆叠式10M/100M 自适应集线器，将服务器和最多47 台工作站组成一个局域
网。另一种情况则是各工作站的网络通信除了与服务器之间的通信外，工作站之间还存在大量通信，这种情况下就应该采用交换机。比较经济的法是采用一台8 口的10M/100M 交换机做中心交换机，下带两台有1 个100M 口、24 个10M 口的交换机来组建局域网。如果10M 还不能满足工作站间的网络通信需求，就全部采用10M/100M 自适应交换机。
双绞线：采用5 类或超5 类双绞线，每根UTP 需要两个RJ-45 连接器（俗称水晶头）。
所有硬件准备好后，用双绞线将每一台工作站、服务器中的网卡与集线器连接起来，局域网硬件部分就大功告成，接下来就到软件部分的安装。
3．操作系统的选择服务器的采用Windows 2000 Server 网络操作系统，工作站可采用Windows 9x、Windows
Me 或Windows 2000 Professional 操作系统，配置好服务器的服务设置和网络配置之后，安装好工作站的操作系统及网络相关设置，便可进行局域网的整体调试，调试通过，局域网组建工作完成。

posted @ 2006-04-11 13:32 青蛙學堂 阅读(310) | 评论 (0) | 编辑 收藏

清除執行內容

開始->內容->開始功能表->自定->進街->清除

posted @ 2006-03-27 16:43 青蛙學堂 阅读(155) | 评论 (0) | 编辑 收藏

如何访问局域网

posted @ 2006-03-09 13:51 青蛙學堂 阅读(4691) | 评论 (8) | 编辑 收藏

FW : 联入公司局域网

posted @ 2006-03-09 12:07 青蛙學堂 阅读(260) | 评论 (0) | 编辑 收藏

FW : ORACLE锁的管理

ORACLE里锁有以下几种模式: 

0：none 
1：null 空 
2：Row-S 行共享(RS)：共享表锁，sub share 
3：Row-X 行独占(RX)：用于行的修改，sub exclusive 
4：Share 共享锁(S)：阻止其他DML操作，share 
5：S/Row-X 共享行独占(SRX)：阻止其他事务操作，share/sub exclusive 
6：exclusive 独占(X)：独立访问使用，exclusive 

数字越大锁级别越高, 影响的操作越多。

1级锁有：Select，有时会在v$locked_object出现。
2级锁有：Select for update,Lock For Update,Lock Row Share 
select for update当对话使用for update子串打开一个游标时，所有返回集中的数据行都将处于行级(Row-X)独占式锁定，其他对象只能查询这些数据行，不能进行update、delete或select for update操作。
3级锁有：Insert, Update, Delete, Lock Row Exclusive
没有commit之前插入同样的一条记录会没有反应, 因为后一个3的锁会一直等待上一个3的锁, 我们必须释放掉上一个才能继续工作。
4级锁有：Create Index, Lock Share
locked_mode为2,3,4不影响DML(insert,delete,update,select)操作, 但DDL(alter,drop等)操作会提示ora-00054错误。
00054, 00000, "resource busy and acquire with NOWAIT specified"
// *Cause: Resource interested is busy.
// *Action: Retry if necessary.
5级锁有：Lock Share Row Exclusive 
具体来讲有主外键约束时update / delete ... ; 可能会产生4,5的锁。
6级锁有：Alter table, Drop table, Drop Index, Truncate table, Lock Exclusive

以DBA角色, 查看当前数据库里锁的情况可以用如下SQL语句：

col owner for a12
col object_name for a16
select b.owner,b.object_name,l.session_id,l.locked_mode
from v$locked_object l, dba_objects b
where b.object_id=l.object_id
/

select t2.username,t2.sid,t2.serial#,t2.logon_time 
from v$locked_object t1,v$session t2 
where t1.session_id=t2.sid order by t2.logon_time
/

如果有长期出现的一列，可能是没有释放的锁。我们可以用下面SQL语句杀掉长期没有释放非正常的锁：

alter system kill session 'sid,serial#';

如果出现了锁的问题, 某个DML操作可能等待很久没有反应。

当你采用的是直接连接数据库的方式，也不要用OS系统命令 $kill process_num 
或者 $kill -9 process_num来终止用户连接，因为一个用户进程可能产生一个以上的锁, 杀OS进程并不能彻底清除锁的问题。

crazybaw 回复于：2003-09-22 19:09:57 这种操作只适合有用户会话的，假设在USERNAME字段中是空的呢，这样做的时候ORACLE会报错，提示“会话不是用户会话”，请问该如何处理 操作和结果如下： select t2.username,t2.sid,t2.serial#,t2.logon_time  from v$locked_object t1,v$session t2  where t1.session_id=t2.sid order by t2.logon_time  结果： username为空 ，sid为5， serial#为1， logon_time为一3天前的时间 ，然后执行alter system kill session '5,1#'; ORACLE报错，提示“会话不是用户会话”，无法删除。  crazybaw 回复于：2003-09-22 19:16:46 请问我执行查询：select b.owner,b.object_name,l.session_id,l.locked_mode  from v$locked_object l, dba_objects b  where b.object_id=l.object_id  得到的结果如下： owner=SYS，OBJECT_NAME=FET$,SESSION_ID,LOCKED_MODE=3，请问该如何处理？字段OBJECT_NAME=FET$和LOCKED_MODE=3表示什么？LOCKED_MODE=3是否表示Row-X 行独占(RX)：用于行的修改，sub exclusive？  rollingpig 回复于：2003-09-23 08:54:49 alter system kill session '5,1';  wxx 回复于：2003-09-23 10:41:35 这种问题在Oracle8i中会比较常遇到，特别是在本地网计费项目中，因为当时Oracle狂推OPS，但是许多集成商的OPS的使用能力实在有限，所以常常会因为OPS导致许多问题，特别是在销账高峰期常常会出问题：数据库被挂死，一个节点的Instance出问题，另外一个也就被挂死了。 这些问题的解决关键要设置好OPS的相关参数，以及相关库表的存储参数才能解决问题，而且在销账高峰期要尽量避免想其他的大事务操作，否则因为都要操作数据字典也会带来一些问题。  crazybaw 回复于：2003-09-23 11:24:02 [quote:1a0cf9cf18="rollingpig"]alter system kill session '5,1';[/quote:1a0cf9cf18]      呵呵，我用的就是alter system kill session '5,1'，只不过在上面的帖子手误而已。  crazybaw 回复于：2003-09-23 11:30:38 [quote:da7fe0de27="wxx"]这种问题在Oracle8i中会比较常遇到，特别是在本地网计费项目中，因为当时Oracle狂推OPS，但是许多集成商的OPS的使用能力实在有限，所以常常会因为OPS导致许多问题，特别是在销账高峰期常常会出问题：数据库被挂死，?.........[/quote:da7fe0de27]      出现该情况的条件很多，电信上面的确暴露的比较明显  rollingpig 回复于：2003-09-23 11:30:58 呵呵 那就郁闷了  peterking 回复于：2003-09-23 11:48:20 交易通过CICS调用ORACLE的，一般不应该直接kill session。应该找出session 对应的process id，在操作系统中kill -9 pid，锁可以自动释放。  zhaoyang 回复于：2003-09-26 21:50:15  flysnowpp 回复于：2003-09-27 09:36:23 用9i的RAC就好多了，锁的问题解决了不少。 [quote:5e5ba27208="wxx"]这种问题在Oracle8i中会比较常遇到，特别是在本地网计费项目中，因为当时Oracle狂推OPS，但是许多集成商的OPS的使用能力实在有限，所以常常会因为OPS导致许多问题，特别是在销账高峰期常常会出问题：数据库被挂死，?.........[/quote:5e5ba27208]

转自http://www.dbonline.cn/source/oracle/20031217/BACKUP_unsafe%20factor%20and%20illuminate%20of%20oracle8i.html

作为对象关系型数据库的杰出代表，Oracle无疑是最具实力的。无论是在数据库的规模，多媒体数据类型的支持，SQL操作复制的并行性还是在安全服务方面，Oracle均比SYBASE、Informix强许多，加上其最新版本Oracle8.0.4更是增强了这方面的特性，而且还引入了一些新的特性，比如：数据分区(Data Partitioning)、对象关系技术(Object Relational Technology)、唯索引表(Index only tables)、连接管理器(Connection Manager)[NET8特性]、高级队列(Advanced Quening)等，所以有一种说法：Oracle8是适用于如Peoplesoft，SAP和Baan等封装式应用系统最好的数据库引擎。

　　虽然Oracle8有许多的优点，但正如微软的WINDOWS系统也会死机一样，任何再好的软件也有他的缺陷，一个优秀的软件不可能就是十全十美，他只是避免了大多数常见的或者可能被考虑到的问题，而一些不容易被发现却非常致命的问题往往会被疏忽掉。Oracle8也同样存在着不安全的因素，许多正在想尽快升级到Oracle8的Oracle7.1、Oracle7.2、Oracle7.3用户不能不考虑到这个因素。当然，这个不安全因素并不是一下子就发现的，而是我们在对一个非常庞大的表进行管理时发现的，这种隐患在使用Oracle创建的小型或者中型数据库中可能不会出现或根本无法发现，因为Oracle8独有的特性已经将这种隐患降低到最低的程度，你大可放心你的数据库系统的安全。

问题

　　我们安装的Oracle8数据库是工作于主机-终端方式下的，系统主机采用的是四台HP-9000小型机、1.5G的内存。建库初期时设定的最大事务数是按Oracle8的默认取值[这也是Oracle7的默认取值]取的：块值为2K，事务数为32（对于一个要处理非常庞大的数据库时，一般我们设定的块值要大于2K，至少应为4K或者16K，当然这还与主机的CPU能力和I/0能力值有关），并在建库时没有进行分区建表，这也许就为以后数据库出问题留下了隐患。由于日访问数据库的用户非常多，而且对同一表操作的用户数量太大，致使那个表经常被锁住，不断有用户抱怨他们进不了系统，主机发送的数据包太慢，经常报ORA-600的错误。起初我们以为是系统网络问题，但这种可能性比较小，因为我们发现系统CPU峰值经常在90%多，空闲很小，数据库资源太忙，同时有十多个人锁住一个大表进行操作，自然一部分用户就无法进入系统，对此我们写了如下的SQL语句对锁表用户进行监控：

SELECT OBJECT_ID,SESSION_ID,SERIAL#,
ORACLE_USERNAME,OS_USER_NAME,S.PROCESS
FROM V$LOCKED_OBJECT A,
V$SESSION S WHERE A.SESSION_ID=S.SID;

也许有的人会问为什么不用如下的SQL语句进行查询：

SELECT a.username,a.sid,a.serial#,b.id1,
c.sql_text from v$session a,
V$lock b,v$sqltext c where a.lockwait=b.kaddr and
a. sql_address=c.address and a.sql_hash_value=c.hash_value;

　　以上两个SQL语句都会查询返回当前被锁住的用户列表，但第二个SQL语句由于加入了sql_text从而使这个查询变得非常的慢长，特别是在有许多用户同时对数据库进行操作时，建议不用，第一个SQL 语句会在很短的时间内查询出是谁在锁表，从而有利于对数据库的管理，一但有用户进入不了，我们就马上杀死其锁进程[SID，SERIAL#]，SQL语句如下：ALTER SYSTEM KILL SESSION ‘SID，SERIAL#'，但这并不是解决问题的根本方法，只能暂时缓解一下；另外我们还发现回滚段时常有“online”与“offline”的现象，于是我们又考虑是否是回滚段引起的问题：因为我们一但对大的回滚段进行操作，马上就会有用户反映无法进入。我们知道回退段的大小直接依赖于数据库的活动状态，而每一个EXTENTS都应具有相同的值（Oracle的推荐）[INITIAL EXTENTS的值可以从2K（32）、4K（69）、8K（142）、16K、32K等列表中选择]，这将保证你删掉一个区的时候，你可以重新使用它的空间而不会造成浪费，另外MINEXTENTS应设为20，这将不会使回退段扩展另一个EXTENT时用到正在被活动的事务所使用的空间，因而我们就可以据此来确定回退段大小，查出数据库正常运行时所需回滚段的尺寸,为此我们重新设置了回退段的OPTIMAL参数[事实是OPTIMAL的值并不足引起数据库出错]，增大了OPTIMAL的值，使用命令SET TRANSACTION USE ROLLBACK SEGMENT为系统指定了一个大的回退段[注意OPTIMAL参数要足够大以使ORACLE不需经常回缩和重新分配EXTENTS，如果设得小于最小覆盖值，性能将由于额外的段重设置而下降，对于一个要执行长查询的系统，OPTIMAL应设成足够大以避免ORA-1555，“Smapshot too old”的错误，而对于运行小的事务，OPTIMAL应设得小一些，使回退段足够小以便放于内存中，这将提高系统性能。]，但我们发现这样做后，ORA-600的错误依然出现，而且锁表越来越严重；我们又考虑暂时锁住这个表，不让用户进入，先把用户的锁进程全部杀完再看，由于一开始就采用了主机-终端的工作方式，因而根本就无法清除得完，除非断掉外部的所有网络连接，但那样无疑是重启数据库，最终我们选择了重启数据库。

　　重启数据库后系统资源一下子得以释放，用户明显感觉速度上来了，能够保证正常使用，就在我们认为系统可能是因为长期没有DOWN机，用户登录数过多造成数据库死锁的时候，一个非常严重的问题出现了，那个表中的一个数据无法进行UPDATE，一UPDATE就报ORACLE内部代码错误，当时我们并没在意，但是不久，我们又发现另一表中编号有重复的现象，根据ORACLE8的数据唯索引表性，这种现象应该根本不会存在，因为我们在这个表中只建立了唯一索引，于是我们电话询问ORACLE公司的技术工程师，也许ORACLE的技术工程师们也是第一次遇到这种问题，他们的回答是数据字典太老，数据索引坏掉，建议重建索引，并把问题向亚太反映。在ORACLE公司的技术工程师的指导下，我们重建了该表，并重新建立了索引，在重建索引过程中，开始几次都不成功，而且无法DROP掉先前的表，经过仔细的查找，我们发现ORACLE8中的确有索引重复的现象，一个表中有两条重复的索引，直接导致数据库HANG，不能访问，但查看系统状态、进程、LISTENER却都正常，从日志文件来看，文件过小（7MB），CHECK POINT频繁，影响到了系统的性能，通过以上调整后，数据库问题暂时缓解了，可以做UPDATE，但是ORACLE的内部代码错误却依然存在，只是暂时还不会影响到我们对数据库的使用，而回滚段开始出现“online rollback segment”的问题，更加令人不解的是数据库居然出现了自动DOWN机的现象，于是我们再次询问ORACLE公司的技术工程师，他们的答复是ORACLE已经注意到了ORACLE8.0.4版本的一些问题，他们将会给数据库打PATCH，希望能够解决到这些问题，但是考虑到给数据库打一个PATCH，将会把所有的数据都要EXPORT出来，这将是一个非常危险的操作，而且所有主机上的程序都要重新编译一到，没有一个星期的时间是无法做好的，而那是根本不可能的事情，因而我们现在还在等待ORACLE公司一个更好的解决办法。

说明

　　以上问题可能是ORACLE的一个BUG，但任何软件都有它不完善的一面，否则又何必出什么补丁了，有了补丁肯定会比没有补丁强，但是我们在设计一个系统时也一定要考虑到以下的一些方面：

　　1、 主机系统的CPU能力与I/0能力：HP偏重于I/0能力，CPU能力不强，你的数据库就应该尽量避免让CPU占用率太大；DEC偏重于CPU能力，I/0能力不强，你的数据库就可以考虑适当增大某些占用CPU参数的设置；SUN的CPU能力与I/0能力差不多，你的数据库就应该考虑平衡参数，过大过小都不好。

　　2、 增大日志文件的SIZE，至少不会低于8MB，日志文件过小会导致CHECK POINT频繁，从而影响到系统的性能。

　　3、 回滚段最好保持一个比较合理的值，对一些较大的回滚段可适当增加MINEXTENTS，并设置OPTIMAL，保证一般事物处理无需经常动态分配空间与及时回收空间。

　　4、 要充分利用CPU系统资源及提高CPU的命中率，可适当增大log_simultaneous_copies,db_block_latches,db_writes的设置。

　　5、 适当增加db_block_buffera与share_pool_size的SIZE，以提高BUFFER值，增加内存，尽快提高BUFF及SQL的命中率。

　　6、 主机-终端方式尽管可以便于数据维持，但主机-终端方式却造成主机负荷太重，建议采用客户-服务端方式建系统。

posted @ 2006-02-22 16:34 青蛙學堂 阅读(937) | 评论 (0) | 编辑 收藏

FW : ORACLE备份策略

前言 

    这篇文章，本是我为CSDN写的，面向对象为中低用户，但考虑到这里也有人问过这样

的问题，偶就往这里也复制一份。在读该文章之前，建议对ORACLE构架有所了解，因为

ORACLE的备份与恢复，都是与ORACLE的构架紧密相关的，特别是ORACLE的SCN。
 
    关于备份与恢复的文章，网上也有不少，进入Google,输入ORACLE备份，点击搜索，

我相信搜索出来的记录没有一个人能读完，但是大部分不是太老，也就是太不完全，很早我

就想总结一下了，我的这篇文章，主旨并不是说大家读了这篇文章，就会了备份的相关知

识，它仅仅也是一个提示，希望大家能从中得到益处。

概要 
1、了解什么是备份 
2、了解备份的重要性 
3、理解数据库的两种运行方式 
4、理解不同的备份方式及其区别 
5、了解正确的备份策略及其好处 

一、了解备份的重要性 

可以说，从计算机系统出世的那天起，就有了备份这个概念，计算机以其强大的速度处理能力，

取代了很多人为的工作，但是，往往很多时候，它又是那么弱不禁风，主板上的芯片、主板电

路、内存、电源等任何一项不能正常工作，都会导致计算机系统不能正常工作。当然，这些损坏

可以修复，不会导致应用和数据的损坏。但是，如果计算机的硬盘损坏，将会导致数据丢失，此

时必须用备份恢复数据。 

其实，在我们的现实世界中，已经就存在很多备份策略，如RAID技术，双机热备，集群技术发

展的不就是计算机系统的备份和高可用性吗？有很多时候，系统的备份的确就能解决数据库备份

的问题，如磁盘介质的损坏，往往从镜相上面做简单的恢复，或简单的切换机器就可以了。 

但是，上面所说的系统备份策略是从硬件的角度来考虑备份与恢复的问题，这是需要代价的。我

们所能选择备份策略的依据是：丢是数据的代价与确保数据不丢失的代价之比。还有的时候，硬

件的备份有时根本满足不了现实需要，假如你误删了一个表，但是你又想恢复的时候，数据库的

备份就变的重要了。ORACLE本身就提供了强大的备份与恢复策略，这里我们只讨论ORACLE

备份策略，以下的备份都是指ORACLE数据库备份，恢复将放到下一讲中。
 
所谓备份，就是把数据库复制到转储设备的过程。其中，转储设备是指用于放置数据库拷贝的磁

带或磁盘。 

能够进行什么样的恢复依赖于有什么样的备份。作为 DBA，有责任从以下三个方面维护数据库

的可恢复性： 

·使数据库的失效次数减到最少，从而使数据库保持最大的可用性； 

·当数据库不可避免地失效后，要使恢复时间减到最少，从而使恢复的效率达到最高； 

·当数据库失效后，要确保尽量少的数据丢失或根本不丢失，从而使数据具有最大的可恢复

性。 

灾难恢复的最重要的工作是设计充足频率的硬盘备份过程。备份过程应该满足系统要求的可恢复

性。例如，如果数据库可有较长的关机时间，则可以每周进行一次冷备份，并归档重做日志，对

于24*7的系统，或许我们考虑的只能是热备份。 如果每天都能备份当然会很理想，但要考虑其

现实性。企业都在想办法降低维护成本，现实的方案才可能被采用。只要仔细计划，并想办法达

到数据库可用性的底线，花少量的钱进行成功的备份与恢复也是可能的。 

二、了解ORACLE的运行方式 

ORACLE数据库有两种运行方式：一是归档方式（ARCHIVELOG），归档方式的目的是当数据

库发生故障时最大限度恢复数据库，可以保证不丢失任何已提交的数据；二是不归档方式

(NOARCHIVELOG)，只能恢复数据库到最近的回收点（冷备份或是逻辑备份）。我们根据数据

库的高可用性和用户可承受丢失的工作量的多少，对于生产数据库，强烈要求采用为归档方式；

那些正在开发和调试的数据库可以采用不归档方式。 

如何改变数据库的运行方式，在创建数据库时，作为创建数据库的一部分，就决定了数据库初始

的存档方式。一般情况下为NOARCHIVELOG方式。当数据库创建好以后，根据我们的需要把

需要运行在归档方式的数据库改成ARCHIVELOG方式。 

1、改变不归档方式为为归档方式 

a.关闭数据库，备份已有的数据，改变数据库的运行方式是对数据库的重要改动，所以要对数据

库做备份，对可能出现的问题作出保护。 

b. 修改初试化参数，使能自动存档 

修改（添加）初始化文件init[SID].ora参数： 

log_archive_start=true #启动自动归档 

log_archive_format=ARC%T%S.arc #归档文件格式 

log_archive_dest=/arch12/arch #归档路径 

在8i中，可以最多有五个归档路径，并可以归档到其它服务器，如备用数据库(standby 

database)服务器 

c.启动Instance到Mount状态，即加载数据库但不打开数据库： 

$>SVRMGRL 
SVRMGRL >connect internal 
SVRMGRL >startup mount 
   d.发出修改命令 
SVRMGRL >alter database archivelog; 
SVRMGRL>alter database open; 

2、改变归档状态为不归档状态 

   与以上步骤相同，但有些操作不一样，主要是在以上的b操作中，现在为删除或注释该参数，

在d操作中，命令为 

SVRMGRL >alter database noarchivelog; 

    注意，从归档方式转换到非归档方式后一定要做一次数据库的全冷备份，防止意外事件的发

生。 

posted @ 2006-02-22 16:27 青蛙學堂 阅读(504) | 评论 (2) | 编辑 收藏

FW : ORACLE 数据库管理员的职责

http://www.dbonline.cn

ORACLE 数据库管理员应按如下方式对 ORACLE 数据库系统做定期监控： 
(1). 每天对 ORACLE 数据库的运行状态 , 日志文件 , 备份情况 , 数据库
的空间使用情况 , 系统资源的使用情况进行检查 , 发现并解决问题。
(2). 每周对数据库对象的空间扩展情况 , 数据的增长情况进行监控 , 对数
据库做健康检查 , 对数据库对象的状态做检查。
(3). 每月对表和索引等进行 Analyze, 检查表空间碎片 , 寻找数据库性能
调整的机会 , 进行数据库性能调整 , 提出下一步空间管理计划。对ORACLE
数据库状态进行一次全面检查。
 
每天的工作 
(1). 确认所有的 INSTANCE 状态正常 
登陆到所有数据库或例程 , 检测 ORACLE 后台进程 : $ps –ef|grep ora 
(2). 检查文件系统的使用（剩余空间）。
如果文件系统的剩余空间小于20% ，需删除不用的文件以释放空间。
$df –k 
(3). 检查日志文件和 trace 文件记录 alert 和 trace 文件中的错误。 
连接到每个需管理的系统 
? 使用' telnet ' 
? 对每个数据库 ,cd 到 bdump 目录 , 通常是$ORACLE_BASE/<SID>/bdump 
? 使用 Unix ‘tail' 命令来查看 alert_<SID>.log 文件
? 如果发现任何新的 ORA- 错误 , 记录并解决 
(4). 检查数据库当日备份的有效性。 
对 RMAN 备份方式 : 
检查第三方备份工具的备份日志以确定备份是否成功 
对 EXPORT 备份方式 : 
检查 exp 日志文件以确定备份是否成功 
对其他备份方式 : 
检查相应的日志文件 
(5). 检查数据文件的状态记录状态不是“ online” 的数据文件，并做恢复。 
Select file_name from dba_data_files where status='OFFLINE' 
(6). 检查表空间的使用情况 
SELECT tablespace_name, max_m, count_blocks free_blk_cnt, 
sum_free_m,to_char(100*sum_free_m/sum_m, '99.99') || '%' AS 
pct_free 
FROM ( SELECT tablespace_name,sum(bytes)/1024/1024 AS 
sum_m FROM dba_data_files GROUP BY tablespace_name), 
( SELECT tablespace_name AS fs_ts_name, max
(bytes)/1024/1024 AS max_m, count(blocks) AS count_blocks, 
sum(bytes/1024/1024) AS sum_free_m FROM dba_free_space 
GROUP BY tablespace_name ) 
WHERE tablespace_name = fs_ts_name 
(7). 检查剩余表空间 
SELECT tablespace_name, sum ( blocks ) as free_blk , 
trunc ( sum ( bytes ) /(1024*1024) ) as free_m, 
max ( bytes ) / (1024) as big_chunk_k, count (*) as num_chunks 
FROM dba_free_space GROUP BY tablespace_name; 
(8). 监控数据库性能 
运行 bstat/estat 生成系统报告 
或者使用 statspack 收集统计数据 
(9). 检查数据库性能，记录数据库的 cpu 使用、 IO 、 buffer 命中率等等
使用 vmstat,iostat,glance,top 等命令 
(10). 日常出现问题的处理。
 
每周的工作 
(1). 控数据库对象的空间扩展情况 
根据本周每天的检查情况找到空间扩展很快的数据库对象 , 并采取相 
应的措施 
-- 删除历史数据 
--- 扩表空间 
alter tablespace <name> add datafile ‘<file>' size <size> 
--- 调整数据对象的存储参数 
next extent 
pct_increase 
(2). 监控数据量的增长情况 
根据本周每天的检查情况找到记录数量增长很快的数据库对象 , 并采 
取相应的措施 
-- 删除历史数据 
--- 扩表空间 
alter tablespace <name> add datafile ‘<file>' size <size> 
(3). 系统健康检查 
检查以下内容 : 
init<sid>.ora 
controlfile 
redo log file 
archiving 
sort area size 
tablespace(system,temporary,tablespace fragment) 
datafiles(autoextend,location) 
object(number of extent,next extent,index) 
rollback segment 
logging &tracing(alert.log,max_dump_file_size,sqlnet) 
(4). 检查无效的数据库对象 
SELECT owner, object_name, object_type FROM dba_objects 
WHERE status= ' INVALID '。 
(5). 检查不起作用的约束 
SELECT owner, constraint_name, table_name, 
constraint_type, status 
FROM dba_constraints 
WHERE status = 'DISABLED' AND constraint_type = 'P' 
(6). 检查无效的 trigger 
SELECT owner, trigger_name, table_name, status 
FROM dba_triggers 
WHERE status = 'DISABLED' 

每月的工作 
(1). Analyze Tables/Indexes/Cluster 
analyze table <name> estimate statistics sample 50 percent; 
(2). 检查表空间碎片 
根据本月每周的检查分析数据库碎片情况 , 找到相应的解决方法 
(3). 寻找数据库性能调整的机会 
比较每天对数据库性能的监控报告 , 确定是否有必要对数据库性能进行调整 
(4). 数据库性能调整 
如有必要 , 进行性能调整 
(5). 提出下一步空间管理计划 
根据每周的监控 , 提出空间管理的改进方法

posted @ 2006-02-22 16:23 青蛙學堂 阅读(281) | 评论 (0) | 编辑 收藏

FW : Oracle DBA 日常管理

目的：这篇文档有很详细的资料记录着对一个甚至更多的 ORACLE 数据库每天的，每月的，每年的运行的状态的结果及检查的结果，在文档的附录中你将会看到所有检查，修改的SQL和 PL/SQL 代码。 

目录 

1. 日常维护程序 
A ． 检查已起的所有实例 
B ． 查找一些新的警告日志 
C ． 检查 DBSNMP 是否在运行 
D ． 检查数据库备份是否正确 
E ． 检查备份到磁带中的文件是否正确 
F ． 检查数据库的性能是否正常合理，是否有足够的空间和资源 
G ． 将文档日志复制到备份的数据库中 
H ． 要常看 DBA 用户手册 
2. 晚间维护程序 
A ．收集 VOLUMETRIC 的数据 
3. 每周维护工作 
A ． 查找那些破坏规则的 OBJECT 
B ． 查找是否有违反安全策略的问题 
C ． 查看错误地方的 SQL*NET 日志 
D ． 将所有的警告日志存档 
E ． 经常访问供应商的主页 
4. 月维护程序 
A ． 查看对数据库会产生危害的增长速度 
B ． 回顾以前数据库优化性能的调整 
C ． 查看 I/O 的屏颈问题 
D ． 回顾 FRAGMENTATION 
E ． 将来的执行计划 
F ． 查看调整点和维护 
5. 附录 
A ． 月维护过程 
B ． 晚间维护过程 
C ． 周维护过程 
6. 参考文献 
---------------------------------------------------------------- 

一．日维护过程 

A ．查看所有的实例是否已起 
确定数据库是可用的，把每个实例写入日志并且运行日报告或是运行测试 
文件。当然有一些操作我们是希望它能自动运行的。 
可选择执行：用 ORACLE 管理器中的‘ PROBE' 事件来查看 
B ．查找新的警告日志文件 
1. 联接每一个操作管理系统 
2. 使用‘ TELNET' 或是可比较程序 
3. 对每一个管理实例，经常的执行 $ORACLE_BASE/<SID>/bdump 操 
作，并使其能回退到控制数据库的 SID 。 
4. 在提示下，使用 UNIX 中的‘ TAIL '命令查看 alert_<SID>.log ，或是 
用其他方式检查文件中最近时期的警告日志 
5. 如果以前出现过的一些 ORA_ERRORS 又出现，将它记录到数据库 
恢复日志中并且仔细的研究它们，这个数据库恢复日志在〈 FILE 〉中 
C ．查看 DBSNMP 的运行情况 
检查每个被管理机器的‘ DBSNMP' 进程并将它们记录到日志中。 
在 UNIX 中，在命令行中，键入 ps –ef | grep dbsnmp, 将回看到 2 个 
DBSNMP 进程在运行。如果没有，重启 DBSNMP 。 
D ．查数据库备份是否成功 
E ．检查备份的磁带文档是否成功 
F ．检查对合理的性能来说是否有足够的资源 
1. 检查在表空间中有没有剩余空间。 
对每一个实例来说，检查在表空间中是否存在有剩余空间来满足当天 
的预期的需要。当数据库中已有的数据是稳定的，数据日增长的平均 
数也是可以计算出来，最小的剩余空间至少要能满足每天数据的增 长。 
A ） 运行‘ FREE.SQL' 来检查表空间的剩余空间。 
B ） 运行‘ SPACE.SQL' 来检查表空间中的剩余空间百分率 
2. 检查回滚段 
回滚段的状态一般是在线的，除了一些为复杂工作准备的专用 段，它一般状态是离线的。 
a) 每个数据库都有一个回滚段名字的列表。 
b) 你可以用 V$ROLLSTAT 来查询在线或是离线的回滚段的现在状 态 . 
c) 对于所有回滚段的存储参数及名字， 可用 
DBA_ROLLBACK_SEGS 来查询。但是它不如 V$ROLLSTAT 准确。 
3. 识别出一些过分的增长 
查看数据库中超出资源或是增长速度过大的段，这些段的存储参 数需要调整。 
a ） 收集日数据大小的信息， 可以用 
‘ ANALYZE5PCT.SQL '。如果你收集的是每晚的信息， 则可跳过这一步。 
b ） 检查当前的范围，可用‘ NR.EXTENTS.SQL' 。 
c ） 查询当前表的大小信息。 
d ） 查询当前索引大小的信息。 
e ） 查询增长趋势。 
4. 确定空间的范围。 
如果范围空间对象的 NEXT_EXTENT 比表空间所能提供的最大范 
围还要大，那么这将影响数据库的运行。如果我们找到了这个目标，可 
以用‘ ALTER TABLESPACE COALESCE' 调查它的位置，或加另外 的数据文件。 
A ）运行‘ SPACEBOUND.SQL' 。如果都是正常的，将不返回任何行。 
5. 回顾 CPU ，内存，网络，硬件资源论点的过程 
A ）检查 CPU 的利用情况，进到 x:webphase2default.htm =>system 
metrics=>CPU 利用页， CPU 的最大限度为 400 ，当 CPU 的占用保持 
在 350 以上有一段时间的话，我们就需要查看及研究出现的问题。 
G ．将存档日志复制到备用数据库中 
如果有一个备用数据库，将适当的存档日志复制到备用数据库的期望 
位置，备用数据库中保存最近期的数据。 
H. 经常查阅 DBA 用户手册 
如果有可能的话，要广泛的阅读，包括 DBA 手册，行业杂志，新闻 组或是邮件列表。 
------------------------------------------------------------- 

二．晚间维护过程 

大部分的数据库产品将受益于每晚确定的检查进程的运行。 
A. 收集 VOLUMETRIC 数据 
1. 分析计划和收集数据 
更准确的分析计算并保存结果。 
a ） 如果你现在没有作这些的话，用‘ MK VOLFACT.SQL' 来创建测定体积的 表。 
b ） 收集晚间数据大小的信息，用‘ ANALYZE COMP.SQL' 。 
c ） 收集统计结果，用‘ POP VOL.SQL' 。 
d ） 在空闲的时候检查数据，可能的话，每周或每个月进行。 
我是用 MS EXCEL 和 ODBC 的联接来检查数据和图表的增长 
------------------------------------------------------------- 

三．每周维护过程 

A ． 查找被破坏的目标 
1. 对于每个给定表空间的对象来说， NEXT_EXTENT 的大小是相同的，如 
12/14/98 ，缺省的 NEXT_EXTENT 的 DATAHI 为 1G ， DATALO 为 500MB ， 
INDEXES 为 256MB 。 
A ） 检查 NEXT_EXTENT 的设置，可用‘ NEXTEXT 。 SQL' 。 
B ） 检查已有的 EXTENTS ，可用‘ EXISTEXT 。 SQL' 。 
2. 所有的表都应该有唯一的主键 
a ） 查看那些表没有主键，可用‘ NO_PK.SQL' 。 
b ） 查找那些主键是没有发挥作用的，可用‘ DIS_PK.SQL' 。 
c ） 所有作索引的主键都要是唯一的，可用‘ NONUPK 。 SQL' 来检 查。 
3. 所有的索引都要放到索引表空间中。运行‘ MKREBUILD_IDX 。 SQL' 
4. 不同的环境之间的计划应该是同样的，特别是测试环境和成品环境之间的 计划应该相同。 
a ） 检查不同的 2 个运行环境中的数据类型是否一致，可用 
‘ DATATYPE.SQL '。 
b ） 在 2 个不同的实例中寻找对象的不同点， 可用 
‘ OBJ_COORD.SQL '。 
c ） 更好的做法是，使用一种工具，象寻求软件的计划管理器那样的 工具。 
B ． 查看是否有危害到安全策略的问题。 
C ． 查看报错的 SQL*NET 日志。 
1. 客户端的日志。 
2. 服务器端的日志。 
D ． . 将所有的警告日志存档 
E ． . 供应商的主页 
1. ORACLE 供应商 
http://www.oracle.com  
http://technet.oracle.com  
http://www.oracle.com /support 
http://www.oramag.com  
2. Quest Software 
http://www.quests.com  
3. Sun Microsystems 
http://www.sun.com  
---------------------------------------------------------------- 

四．月维护过程 

A ．查看对数据库会产生危害的增长速度 
1. 从以前的记录或报告中回顾段增长的变化以此来确定段增长带来危害 
B ． 回顾以前数据库优化性能的调整 
1. 回顾一般 ORACLE 数据库的调整点，比较以前的报告来确定有害的发展 趋势。 
C ． 查看 I/O 的屏颈问题 
1. 查看前期数据库文件的活动性，比较以前的输出来判断有可能导致屏颈 问题的趋势。 
D ． 回顾 FRAGMENTATION 
E ． 计划数据库将来的性能 
1. 比较 ORACLE 和操作系统的 CPU ，内存，网络，及硬盘的利用率以此 
来确定在近期将会有的一些资源争夺的趋势 
2. 当系统将超出范围时要把性能趋势当作服务水平的协议来看 
F ． 完成调整和维护工作 
1. 使修改满足避免系统资源的争夺的需要，这里面包括增加新资源或使预期 的停工。 
---------------------------------------------------------------- 

五．附录 

A. 日常程序 
--free.sql 
--To verify free space in tablespaces 
--Minimum amount of free space 
--document your thresholds: 
--<tablespace_name> = <amount> m 
SELECT tablespace_name, sum ( blocks ) as free_blk , 
trunc ( sum ( bytes ) / (1024*1024) ) as free_m ,
max ( bytes ) / (1024) as big_chunk_k, 
count (*) as num_chunks 
FROM dba_free_space GROUP BY tablespace_name 
1. Space.sql 
-- space.sql 
-- To check free, pct_free, and allocated space within a tablespace 
-- 11/24/98 
SELECT tablespace_name, largest_free_chunk 
, nr_free_chunks, sum_alloc_blocks, sum_free_blocks 
, to_char(100*sum_free_blocks/sum_alloc_blocks, '09.99') || '%' 
AS pct_free 
FROM ( SELECT tablespace_name , sum(blocks) AS sum_alloc_blocks 
FROM dba_data_files GROUP BY tablespace_name ) 
, ( SELECT tablespace_name AS fs_ts_name 
, max(blocks) AS largest_free_chunk 
, count(blocks) AS nr_free_chunks 
, sum(blocks) AS sum_free_blocks FROM dba_free_space 
GROUP BY tablespace_name ) WHERE tablespace_name = fs_ts_name 
2. analyze5pct.sql 
-- analyze5pct.sql 
-- To analyze tables and indexes quickly, using a 5% sample size 
-- (do not use this script if you are performing the overnight 
-- collection of volumetric data) 
-- 11/30/98 
BEGIN 
dbms_utility.analyze_schema ( '&OWNER', 'ESTIMATE', NULL, 5 ) ; 
END ; 
/ 
3. nr_extents.sql 
-- nr_extents.sql 
-- To find out any object reaching <threshold> 
-- extents, and manually upgrade it to allow unlimited 
-- max_extents (thus only objects we *expect* to be big 
-- are allowed to become big) 
-- 11/30/98 
SELECT e.owner, e.segment_type , e.segment_name , 
count(*) as nr_extents , s.max_extents ,
to_char ( sum ( e.bytes ) / ( 1024 * 1024 ) , '999,999.90') as MB 
FROM dba_extents e , dba_segments s 
WHERE e.segment_name = s.segment_name 
GROUP BY e.owner, e.segment_type , e.segment_name , s.max_extents 
HAVING count(*) > &THRESHOLD 
OR ( ( s.max_extents - count(*) ) < &&THRESHOLD ) 
ORDER BY count(*) desc 
4. spacebound.sql 
-- spacebound.sql 
-- To identify space-bound objects. If all is well, no rows are returned. 
-- If any space-bound objects are found, look at value of NEXT extent 
-- size to figure out what happened. 
-- Then use coalesce (alter tablespace <foo> coalesce . 
-- Lastly, add another datafile to the tablespace if needed. 
-- 11/30/98 
SELECT a.table_name, a.next_extent, a.tablespace_name 
FROM all_tables a, 
( SELECT tablespace_name, max(bytes) as big_chunk 
FROM dba_free_space 
GROUP BY tablespace_name ) f 
WHERE f.tablespace_name = a.tablespace_name 
AND a.next_extent > f.big_chunk 
B. 每晚处理程序 
1. mk_volfact.sql 
-- mk_volfact.sql (only run this once to set it up; do not run it nightly!) 
-- -- Table UTL_VOL_FACTS 
CREATE TABLE utl_vol_facts ( 
table_name VARCHAR2(30), 
num_rows NUMBER, 
meas_dt DATE ) 
TABLESPACE platab 
STORAGE ( 
INITIAL 128k 
NEXT 128k 
PCTINCREASE 0 
MINEXTENTS 1 
MAXEXTENTS unlimited 
) 
/ 
-- Public Synonym 
CREATE PUBLIC SYNONYM utl_vol_facts FOR &OWNER..utl_vol_facts 
/ 
-- Grants for UTL_VOL_FACTS 
GRANT SELECT ON utl_vol_facts TO public 
/ 
2. analyze_comp.sql 
-- 
-- analyze_comp.sql 
-- 
BEGIN 
sys.dbms_utility.analyze_schema ( '&OWNER','COMPUTE'); 
END ; 
/ 
3. pop_vol.sql 
-- 
-- pop_vol.sql 
-- 
insert into utl_vol_facts 
select table_name 
, NVL ( num_rows, 0) as num_rows 
, trunc ( last_analyzed ) as meas_dt 
from all_tables -- or just user_tables 
where owner in ('&OWNER') -- or a comma-separated list of owners 
/ 
commit 
/ 
C. 每周处理程序 
1. nextext.sql 
-- 
-- nextext.sql 
-- 
-- To find tables that don't match the tablespace default for NEXT extent. 
-- The implicit rule here is that every table in a given tablespace should 
-- use the exact same value for NEXT, which should also be the tablespace's 
-- default value for NEXT. 
-- 
-- This tells us what the setting for NEXT is for these objects today. 
-- 
-- 11/30/98 
SELECT segment_name, segment_type, ds.next_extent as Actual_Next 
, dt.tablespace_name, dt.next_extent as Default_Next 
FROM dba_tablespaces dt, dba_segments ds 
WHERE dt.tablespace_name = ds.tablespace_name 
AND dt.next_extent !=ds.next_extent 
AND ds.owner = UPPER ( '&OWNER' ) 
ORDER BY tablespace_name, segment_type, segment_name 
2. existext.sql 
-- 
-- existext.sql 
-- 
-- To check existing extents 
-- 
-- This tells us how many of each object's extents differ in size from 
-- the tablespace's default size. If this report shows a lot of different 
-- sized extents, your free space is likely to become fragmented. If so, 
-- this tablespace is a candidate for reorganizing. 
-- 
-- 12/15/98 
SELECT segment_name, segment_type 
, count(*) as nr_exts 
, sum ( DECODE ( dx.bytes,dt.next_extent,0,1) ) as nr_illsized_exts 
, dt.tablespace_name, dt.next_extent as dflt_ext_size 
FROM dba_tablespaces dt, dba_extents dx 
WHERE dt.tablespace_name = dx.tablespace_name 
AND dx.owner = '&OWNER' 
GROUP BY segment_name, segment_type, dt.tablespace_name, dt.next_extent 
3. No_pk.sql 
-- 
-- no_pk.sql 
-- 
-- To find tables without PK constraint 
-- 
-- 11/2/98 
SELECT table_name 
FROM all_tables 
WHERE owner = '&OWNER' 
MINUS 
SELECT table_name 
FROM all_constraints 
WHERE owner = '&&OWNER' 
AND constraint_type = 'P' 
4. disPK.sql 
-- 
-- disPK.sql 
-- 
-- To find out which primary keys are disabled 
-- 
-- 11/30/98 
SELECT owner, constraint_name, table_name, status 
FROM all_constraints 
WHERE owner = '&OWNER' AND status = 'DISABLED' AND constraint_type = 'P' 
5. nonuPK.sql 
-- 
-- nonuPK.sql 
-- 
-- To find tables with nonunique PK indexes. Requires that PK names 
-- follow a naming convention. An alternative query follows that 
-- does not have this requirement, but runs more slowly. 
-- 
-- 11/2/98 
SELECT index_name, table_name, uniqueness 
FROM all_indexes 
WHERE index_name like '&PKNAME%' 
AND owner = '&OWNER' AND uniqueness = 'NONUNIQUE' 
SELECT c.constraint_name, i.tablespace_name, i.uniqueness 
FROM all_constraints c , all_indexes i 
WHERE c.owner = UPPER ( '&OWNER' ) AND i.uniqueness = 'NONUNIQUE' 
AND c.constraint_type = 'P' AND i.index_name = c.constraint_name 
6. mkrebuild_idx.sql 
-- 
-- mkrebuild_idx.sql 
-- 
-- Rebuild indexes to have correct storage parameters 
-- 
-- 11/2/98 
SELECT 'alter index ' || index_name || ' rebuild ' 
, 'tablespace INDEXES storage ' 
|| ' ( initial 256 K next 256 K pctincrease 0 ) ; ' 
FROM all_indexes 
WHERE ( tablespace_name != 'INDEXES' 
OR next_extent != ( 256 * 1024 ) 
) 
AND owner = '&OWNER' 
/ 
7. datatype.sql 
-- 
-- datatype.sql 
-- 
-- To check datatype consistency between two environments 
-- 
-- 11/30/98 
SELECT 
table_name, 
column_name, 
data_type, 
data_length, 
data_precision, 
data_scale, 
nullable 
FROM all_tab_columns -- first environment 
WHERE owner = '&OWNER' 
MINUS 
SELECT 
table_name, 
column_name, 
data_type, 
data_length, 
data_precision, 
data_scale, 
nullable 
FROM all_tab_columns@&my_db_link -- second environment 
WHERE owner = '&OWNER2' 
order by table_name, column_name 
8. obj_coord.sql 
-- 
-- obj_coord.sql 
-- 
-- To find out any difference in objects between two instances 
-- 
-- 12/08/98 
SELECT object_name, object_type 
FROM user_objects 
MINUS 
SELECT object_name, object_type 
FROM user_objects@&my_db_link 

posted @ 2006-02-22 16:20 青蛙學堂 阅读(243) | 评论 (0) | 编辑 收藏