医保在台PC SERVER上装10.2.0.2小记

因代码申报需要台测试机装上10.2.0.2后测试应用。花了大半天时间下载了10.2.0.1的服务器端、升级包、最新的patch 15后开始装机过程。

在数据库安装前的检查过程中有一警告，关于DHCP的，并没有多想，就忽略了装下去了，装数据库需要点时间，最烦人的还是升级包，容量都赶上一个数据库安装版本的大小了，很花时间。

全搞定后开始EXP源库数据，由于源库就是EXP有毛病，一次根本没法全部导出一个用户下的所有对象，一共249张表，只好分四次导出。三个文件导入到新库都没出什么问题，就是有一个EXP导入就报错，想到前面用U盘插拔时没响应，怀疑是文件损坏，就这么进出机房好几次，汗都出来了，还是没搞定，文件总有问题，真想踢了那破机器，后来问维护部，告诉我那台开了FTP的（早知这样，不用进进出出那么多次，又在里面因USB口不够插来拔去弄的一身汗那么辛苦了。。。）这下很顺利，表也能导入了。

问题来了，我发现数据库无法用操作系统验证的方式登录，检查WINDOWS的用户和组设置，没有问题，ORA_DBA组存在，并且当前用户在该组下，很奇怪。

突然想到刚安装时的关于DHCP的警告（当时不知道DHCP为啥玩意），想着是不是和这个有关联。。。想归想，很晚了先回去再说。

到家后，网上搜了下，在一个英国DBA朋友的BLOG上看到以下内容，仔细看过一遍，为防忘记，转过来给自己再提个醒，下次再不在DHCP上装ORACLE了：

Why Oracle Servers and DHCP don't mix at all, ever

I am having all sorts of mysterious, intermittent problems with my Oracle installation. Someone told me that the fact the machine Oracle is running on is using DHCP might be the cause of the problems. Is that true?

Quite possibly. You should never, ever install Oracle onto a machine that uses DHCP to obtain it's IP address. There are a number of reasons for this:

• It's stupid
• It causes mysterious, intermittent errors
• The Oracle documentation specifically says not to

I'm not stupid!! What's wrong with DHCP?

I didn't say you were stupid. I said using DHCP on a server was stupid. And nothing is wrong with DHCP, but using it when it's inappropriate causes problems, just as trying to hammer in a nail with a toothpick is likely to cause grief: it's not a deficiency in the toothpick, but it's still safe to say you're using the wrong tool to do the wrong job.

Here's a definition of DHCP, taken more or less at random from whatever Google happened to throw at me this morning:

DHCP's purpose is to enable individual computers on an IP network to extract their configurations from a server (the 'DHCP server') or servers, in particular, servers that have no exact information about the individual computers until they request the information. The overall purpose of this is to reduce the work necessary to administer a large IP network. The most significant piece of information distributed in this manner is the IP address.

You might notice reference there to "individual computers" extracting configurations "from servers" and "large IP network". The entire tenor of the piece indicates that DHCP is intended for client PCs, not servers. It also suggests when DHCP is suitable: when there are lots of client machines to be configured (the "˜large network' reference). Now, I realise that if you work in the server room of a large multinational corporation, you may well think that you have a large number of servers which need IP addresses to be allocated... but generally, for most corporate networks, the number of servers will be relatively small. And they also tend to all be physically co-located in one, large, rather chilly, server room. There is therefore no need for servers to have dynamically-assigned IP addresses, and it is laziness or sloppiness that leads system administrators to think that they should.

And this is another definition grabbed at random from Google:

DHCP is a protocol that lets network administrators centrally manage and automate the assignment of IP Addresses on the corporate network. When a company sets up its computer users with a connection to the Internet , an IP address must be assigned to each machine. Without DHCP , the IP address must be entered manually at each computer .

The key features of DHCP are here listed as "˜central management of IP addresses'. Bearing in mind that servers are already, and by definition, at the metaphorical centre of things in a network, it should be obvious that DHCP doesn't apply to them. Notice, too, that companies "set up their computer users with a connection...". For "users", you can usefully read "client". And finally note that DHCP is there because of the pain of otherwise "˜manually entering an IP address at each computer'... which is indeed a pain in the butt when there are 100+ user's PCs to do it to, but is hardly an issue when it involves configuring a dozen or so servers.

There are always exceptions to general rules, of course. So, whilst generally it makes no sense to configure servers themselves to use DHCP, you may find a use for it in your server room regardless. But not on your Oracle servers you won't. Ever.

So this is an Oracle limitation! It's not a DHCP problem, is it?!

Oh, who honestly cares who's limitation it is?! This isn't, or shouldn't be, a blame game. Oracle works the way it does, expecting (sensibly, in my view) to be on a server which doesn't chop and change its IP address at the drop of a hat. Here's what the 10g Installation Guide for Windows has to say on the topic:

In a DHCP setup, the software tracks IP addresses, which simplifies network administration. This lets you add a new computer to the network without having to manually assign that computer a unique IP address. However, before installing Oracle Database onto a computer that uses the DHCP protocol, you need to install a loopback adapter to assign a local IP address to that computer.

They are being polite about it, but what that "however..." means, in effect, is that if you insist on installing onto a machine which uses DHCP, you at least have to pretend that it doesn't. A loopback adapter is a fake NIC, implemented in software, to which you must assign a static IP address before performing the Oracle installation. The documentation then goes on at great length about how to check whether a loopback adapter has been installed, whether it's been assigned a static IP address and so on.

In short, the documentation is saying to you that an Oracle installation demands and requires a static IP address. You can get that most simply by not using DHCP in the first place. Or, if you must use DHCP for other reasons, then there is a mechanism available to you to fake a static IP address. But whichever way you look at it, you must not ever install Oracle onto a machine which, as far as Oracle is concerned, uses dynamic IP addresses.

If you'd like to read the loopback adapter stuff in detail, it's here. You specifically will want to hunt out section 2.4.5.

You might also notice that this loopback adapter approach is recommended particularly for laptops (presumably used only for learning purposes!) which connect and disconnect from the real, corporate network. The loopback adapter means that Oracle will function regardless of whether the laptop is connected to the network or not: it gives Oracle a static, always-there, point of reference independent of what shenannigans the real NIC gets up to. That should give you another clue that having to use the same technique on a real server in a real production server room, whilst eminently do-able, is a trifle odd. That may in turn further reinforce the fundamental message here: don't use DHCP on Oracle Servers.

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/266799/viewspace-927185/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/266799/viewspace-927185/