私は管理者ではありませんが、私たちの常連は休暇中なので、問題は私の膝に終わりました。できるだけ簡単に説明します。
SQL Server 2005インスタンスがおかしな動作をしていることに気づきました。アプリが起動し、アプリがデータベースに接続できません。ただし、アプリは再起動後も問題なく動作します。 SQL Server ManagemetnStudioについても同じことが言えます。この動作はいくつかのネットワークマシンで観察されているため、おそらくクライアントの問題ではありません。同時に、サーバーのIPアドレスの使用は常に機能します。これは、初心者としては名前解決の問題のように見えます。
サーバーに名前でpingを実行すると、最初の試行でDestination Host unreachable
になり、その後の試行でpingが成功します。不確定な時間を待った後、この同じサイクルがiselfを繰り返します。繰り返しますが、サーバーのIPへのpingは問題なく機能します。
イベントビューアのDNSセクションにエラー4004および4015が含まれています。グーグルを使用してそれらを修正する試みはこれまで成功していません。
質問:簡単な修正はありますか?
更新
エラー4015はまだ存在しますが、DNSサービスを再インストールすることでエラー4004を排除することができました。
最初のpingの失敗に関連して私が気付いたもう1つの興味深い点:
Pinging oxyserver [169.254.2.62] with 32 bytes of data:
Reply from 169.254.74.29: Destination Host unreachable.
Reply from 169.254.74.29: Destination Host unreachable.
このIPアドレス(169.254.2.62)がどのように作成されたのかわかりません。その直後に、pingがサーバーのIPアドレスを正しく取得し、正常に機能するためです。
Pinging oxyserver [192.168.1.201] with 32 bytes of data:
Reply from 192.168.1.201: bytes=32 time<1ms TTL=128
Reply from 192.168.1.201: bytes=32 time<1ms TTL=128
pdate2
要求に応じて、dnscmd /info
の結果
Query result:
Server info
server name = oxyserver.Oxy.loc
version = 0ECE0205 (5.2 build 3790)
DS container = cn=MicrosoftDNS,cn=System,DC=Oxy,DC=loc
forest name = Oxy.loc
domain name = Oxy.loc
builtin domain partition = ForestDnsZones.Oxy.loc
builtin forest partition = DomainDnsZones.Oxy.loc
last scavenge cycle = not since restart (0)
Configuration:
dwLogLevel = 00000000
dwDebugLevel = 00000000
dwRpcProtocol = FFFFFFFF
dwNameCheckFlag = 00000002
cAddressAnswerLimit = 0
dwRecursionRetry = 3
dwRecursionTimeout = 15
dwDsPollingInterval = 180
Configuration Flags:
fBootMethod = 3
fAdminConfigured = 0
fAllowUpdate = 1
fDsAvailable = 1
fAutoReverseZones = 1
fAutoCacheUpdate = 0
fSlave = 0
fNoRecursion = 0
fRoundRobin = 1
fStrictFileParsing = 0
fLooseWildcarding = 0
fBindSecondaries = 1
fWriteAuthorityNs = 0
fLocalNetPriority = 1
Aging Configuration:
ScavengingInterval = 0
DefaultAgingState = 0
DefaultRefreshInterval = 168
DefaultNoRefreshInterval = 168
ServerAddresses:
Addr Count = 2
Addr[0] => 192.168.1.201
Addr[1] => 169.254.2.62
ListenAddresses:
NULL IP Array.
Forwarders:
NULL IP Array.
forward timeout = 5
slave = 0
Command completed successfully.
2つのアドレスは明らかな危険信号です。
Network Connections/AdvancedでNICの優先度を変更すると、エラー4015が解消されたようです。ただし、元の問題は引き続き存在します。
最初の試行でAPIPAアドレスが提供されていることを考えると、ネームサーバーが破損しているか、どこかに不正なDNSレコードがあると思う傾向があります。間違ったアドレスを返しているホストのレコードを確認してください。
これを試してください:コマンドプロンプトを開きます。タイプipconfig /flushdns
。次に、サーバーにpingを実行して、何が得られるかを確認します。
サーバーにはNICがいくつありますか? [どういうわけか]別のNICがプライマリNICよりも高い優先度に設定されている場合、このエラーが職場で発生するのを目にしました。
編集 ARPキャッシュを確認できますか?ダニエルはAPIPAで何かに取り組んでいると思います。
コマンドプロンプトを開き、arp -a
と入力して、出力を投稿してください。
「サーバーに名前でpingを実行すると、最初の試行で宛先ホストに到達できなくなります」
ここでは「さらに遠く」かもしれませんが、サーバーのNICの電源管理設定を確認することもできます。通常、すべてがセットアップされて実行された後は変更されません。
切断済みとしてリストされていたが、何らかの理由でIPアドレスが割り当てられていた2番目のネットワークアダプター(TAP-Win32アダプターv9)を無効にすることで、問題を解決することができました。
皆様のご協力に感謝いたします。私を解決策に導いたのは、arp -a
を実行するというJoshの提案でした。 169.x.x.xアドレスに対して何も返されない場合、ipconfig /all
を実行するように促され、他のNICの横に169.x.x.xアドレスが表示されました。単純な無効化とそれに続く再起動により修正されました。