Windows NT 4 & Paradox : résumé
Vous trouverez ici des infos sur la configuration de Windows NT, pour Paradox. Cela, soit pour éviter certains problèmes, soit pour améliorer la vitesse. Les articles ont été copiés "Tels quels".
De mes lectures, j'ai déduit 2 grandes idées :
Pour la vitesse seule, vérifiez que les anti-virus (notamment Norton) ne contrôlent pas les fichiers Paradox (.DB .MB .PX .X* .Y* etc.)
Tips
for NT Configuration, based on newsgroup postings
and other FAQ's:
Version 1.0 (2000.06.09)
written by Lance Leonard
commented on by Liz, Dmitry Vulis, Denn Santoro
edited by Paradox FAQ Team
Reposted by Mike Irwin: 2001.02.10
commented on by Adam Lackie
Updated by Mike Irwin:2001.02.10
====================
0. Introduction
====================
This FAQ covers a set of tips garnered from users'
experience as discussed on Paradox NewsGroups.
This FAQ is appropriate to users of all versions of
32-bit Paradox for Windows (7/32, 8, 9, and later).
This document was originally written in a monospaced
font. To make things more easily readable you may wish
to copy it into NotePad.
-------------------------------
0.1 Legal Info and Disclaimers
-------------------------------
Paradox is a trademark of Corel.
Borland Database Engine (BDE) is a trademark of Inprise.
Windows, Windows NT, etc. are trademarks of Microsoft.
The information provided in this FAQ is provided "as is"
and is not warranted in any way. The information provided
in this FAQ is not endorsed or authorized by Corel or
Inprise in any shape, form, or manner. The editors claim
NO responsibility for ANY illegal activity regarding this
file, or as a result of someone reading this file.
You may distribute this file, as long as the copies are
complete, unaltered, and are in electronic form only.
-------------
0.2 Feedback
-------------
Please send feedback in a Corel Paradox newsgroup or the
news:comp.databases.Paradox
newsgroup to any of the FAQ
Team mentioned in the "FAQ: FAQ FAQ" document.
Please preface the subject of your post with the string
"PDXWIN FAQ" to alert Team members to the function
of the message.
Please specify the FAQ name and section number the
comment applies to, if any.
==============================
1. General Problem Information
==============================
Users sometimes experience problems when using
Windows NT as a server machine for a network of
machines running Paradox. This can be remedied by
some registry changes as outlined in another FAQ.
This document offers a broader range of assistance.
This document should also be appropriate for users
of Windows NT 5 - called Windows 2000.
===============
2. References
===============
Please also refer to other FAQs, in particular:
FAQ: PdoxWin: Text Full FAQ 1999.06.30
FAQ:PdoxWin:Net File Rules:2000.01.18
===============
3. Tips
===============
1. Change the opportunistic locking on the NT server to
false. You may need to add settings to the Registry to
do this. In the
HKEY_LOCAL_MACHINES\System\CurrentControlSet\Services\
LanmanWorkstation\Parameters
section, change (or add) the UseOpportunisticLocking key
to a value of 0 (zero, decimal).
For more information, see Appendix A, which is based on
a Microsoft KnowledgeBase document, and/or the FAQ on
the subject.
Newgroup reports suggest that this change seems to take
effect even though the machine has not been restarted.
2. Create a non-root directory for the PDOXUSRS.NET file
and map this directory to a drive letter.
For example, T:\netdir.
This needs to be visible and writeable to all users.
See other FAQ: The Net Dir should never actually be the
root of a drive, logical or physical.
3. Set all users' BDE configration files to use this
directory as the NET DIR value. This is required for
networking (see other FAQ).
4. If you wish to force each user to use the same net
file, which is definitely the recommended procedure, it
may help to specify this in the Paradox command-line.
For example, use the following switch and path
-o"T:\Netdir\idapi.cfg"
You may also wish to configure each user's BDE
Administrator to use this shared CFG as the default CFG
file. Using a single .CFG file helps ensure that
everyone has access to the same aliases, network control
file settings, and so on.
However, to do this, you must ensure that common areas
are named the same as seen from each participating PC.
5. Each workstation should have at least 32MB of RAM or
performance will very likely suffer. Also, workstations
should give priority to local processes.
6. When configuring printers, it may help to set the
Default printer so that
a) it's captured to one of the local LPT ports (to put
it another way, don't use UNC),
b) it has a short name, one that does _not_ contain
spaces,
c) if it is a newer HP printer, it uses an earlier
driver.
7. If you are using a Novell network and are using the
Novell client, consider changing to the Microsoft
client, uninstalling the Novell client, and deleting
extra, unused protocols. (There are reports of extra
protocols slowing NT down.) If you are already using the
MS client, try switching to the Novell client. (Get the
latest from Novell website, though. There are known
issues with some earlier versions of Client32.)
8. If all of the server's clients are using Windows 9x,
you may wish to consider using UNC's references instead
of drive mappings. UNC's tend to run more quickly.
However, if you have older versions of Paradox (7.32 or
earlier) you probably won't be able to do this. If you
have NT clients however, use drive mappings.
9. You may be able to improve performance by running
Paradox or the application locally. While this imposes
a maintenance hit, it reduces the amount of network
traffic involved in loading the various files. There is
a third party tool called AutoReplicator that helps
manage the maintance burden. More information can be
found at
http://www.RDAWorldWide.Com/RDAprod.htm
10. If you are using NT4, please make sure you are using
service Pack 4 or later. SP5 is not recommended. SP6 was
withdrawn, but 6a appears good. Earlier service packs
have been reported to have problems.
11. You will get better I/O performance from a SCSI drive
on the server, rather than IDE drives.
12. There are reports that you may not want to use the
IPX/SPX protocol. On the other hand, other people have
experienced problems with only the MS version !
13. Novell's latest client (Client 3.20) is reported to
have some problems with the file locks, which were
reported on Novell NGs. This has implications on Paradox
applications as well. It may be best to remain with
Client 3.10 with SP 2 (the last version prior to 3.20)
which seems to give best results.
14. UNC vs Mapped Drives. You should get better performance
with UNC calls in Win9x and with mapped drives in Win NT
regardless of the protocols. This has to do with NT's
design feature of checking ALL installed protocols for a
UNC call even if it finds it on the first one.
15. You may experience extreme lethargy when using Win 98SE
clients and Win NT 4 servers. In addition to the
registry setting change outlines in item 1 here, you can
also try, in this case, setting the following regisytry
key on the server:
HKEY_LOCAL_MACHINES\System\CurrentControlSet\Services\
LanmanWorkstation\Parameters\
setting the value as follows:
EnableOplocks=0 (DWORD)
You may need to create both key and value.
It has been reported that this may yield significant
increases in speed.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-
Appendix A: An Explanation of Opportunistic Locking on
Windows NT
(from Microsoft
Knowldgebase Article #Q129202)
-- Microsoft Mail for PC Networks versions 3.0, 3.2, and
3.2a
-- Microsoft Windows NT Workstation version 3.5, 3.51, and
4.0
-- Microsoft Windows NT Server version 3.5, 3.51, and 4.0
SUMMARY
With Exclusive Oplock, if a file is opened in a non-
exclusive (deny none) mode, the redirector requests an
opportunistic lock of the entire file. As long as no other
process has the file open, the server will grant this
oplock, giving the redirector exclusive access to the
specified file. This will allow the redirector to perform
read-ahead, write-behind, and lock caching, as long as no
other process tries to open the file.
When a second process attempts to open the file, the
original owner will be asked to Break Oplock or Break to
Level II Oplock. At that point, the redirector must
invalidate cached data, flush writes and locks, and release
the oplock, or close the file.
Opportunistic Locking level II, provides a method for
granting read access to a file by more than one
workstation, and these workstations can cache read data
locally (read-ahead). As long as no station writes to the
file, multiple stations can have the file open with level
II oplock.
MORE INFORMATION
An illustration of how level II oplocks work:
1. Station 1 opens the file, requesting oplock.
2. Since no other station has the file open, the server
grants station 1 exclusive oplock.
3. Station 2 opens the file, requesting oplock.
4. Since station 1 has not yet written to the file, the
server asks station 1 to Break to Level II Oplock.
5. Station 1 complies by flushing locally buffered lock
information to the server.
6. Station 1 informs the server that it has Broken to
Level II Oplock (alternatively, station 1 could have
closed the file).
7. The server responds to station 2's open request,
granting it level II oplock. Other stations can likewise
open the file and obtain level II oplock.
8. Station 2 (or any station that has the file open) sends
a write request SMB. The server returns the write
response.
9. The server asks all stations that have the file open to
Break to None, meaning no station holds any oplock on
the file. Because the workstations can have no cached
writes or locks at this point, they need not respond to
the break-to-none advisory; all they need do is
invalidate locally cashed read-ahead data.
The following registry entries are used to enable or
disable oplocks for Windows NT workstation or server. To
access the registry run REGEDT32.EXE from the File menu,
choose Run in Program Manager or File Manager.
WARNING: Using Registry Editor incorrectly can cause
serious, system-wide problems that may require you to
reinstall Windows NT to correct them. Microsoft cannot
guarantee that any problems resulting from the use of
Registry Editor can be solved. Use this tool at your own
risk.
-----------------------------
Workstation Service Entries
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Services\LanmanWorkstation\Parameters
UseOpportunisticLocking REG_DWORD 0 or 1
Default: 1 (true)
Indicates whether the redirector should use opportunistic-
locking
(oplock) performance enhancement. This parameter should be
disabled only to isolate problems.
-----------------------------
Server Service Entries
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Services\LanmanServer\Parameters
EnableOplocks REG_DWORD 0 or 1
Default: 1 (true)
Specifies whether the server allows clients to use oplocks
on files. Oplocks are a significant performance
enhancement, but have the potential to cause lost cached
data on some networks, particularly wide-area networks.
MinLinkThroughput REG_DWORD 0 to infinite bytes per
second
Default: 0
Specifies the minimum link throughput allowed by the server
before it disables raw and opportunistic locks for this
connection.
MaxLinkDelay REG_DWORD 0 to 100,000 seconds
Default: 60
Specifies the maximum time allowed for a link delay. If
delays exceed this number, the server disables raw I/O and
opportunistic locking for this connection.
OplockBreakWait REG_DWORD 10 to 180 seconds
Default: 35
Specifies the time that the server waits for a client to
respond to an oplock break request. Smaller values can
allow detection of crashed clients more quickly but can
potentially cause loss of cached data.
Récupéré, je ne me rappelle plus où :
Client
Windows 95 (en réseau sous Windows NT) : ajoutez la clef de registre suivante
:
HKEY_LOCAL_MACHINES\System\\CurrentControlSet\Services\VxD\Vredir\
puis ajoutez la chaîne de caractères suivante :
DiscardCacheonOpen avec la valeur 1. Notez que cette clef
de registre n'est pas documentée. Pour toutes questions, voir directement
Microsoft . (Articles Microsoft : Q174371
and Q165403)
Windows NT : des problèmes apparaissent du fait du verrouillage opportuniste. Il faut modifier une clef d'accès dans la registry et positionner le verouillage opportuniste à faux. (Article Microsoft Q129202)
-------------------------------------------
Posté par Arcade, le 23.08.2000, sur la NG nzn.fr.base-de-données :
« Je
viens par ailleurs d'avoir la solution : le serveur était sous sp4, les
postes sous sp6 (tout ce qu'il ne faut pas faire je vois !). En passant le
serveur sous sp6, tout est rentré dans l'ordre sans autres modifs. »
Posté par Philippe, le 25.08.2000, sur la NG www.monbestof.com
(fichier « MAJ reseau.zip »)
Fichier
contenant les modifications à faire sur les serveurs NT4 et 2000
ainsi que sur les postes Win9x pour résoudre des problèmes de lenteur ou de
corruption de donnée.
Modifications à apporter.
Les postes concernés sont :
· le serveur NT
· la totalité des postes des techniciens
Articles de Microsoft :
Problème de corruption de données :
article 148367 : (windows95)
http://support.microsoft.com/support/kb/articles/Q148/3/67.asp?LNG=ENG&SA=PER
article 174371 : (windows95)
http://support.microsoft.com/support/kb/articles/Q174/3/71.ASP?LNG=ENG&SA=PER
article 129202 : (Windows NT WorkStation et NT Server)
http://support.microsoft.com/support/kb/articles/Q129/2/02.asp?LNG=ENG&SA=PER
article 163401 : (Windows NT WorkStation et NT Server)
http://support.microsoft.com/support/kb/articles/Q163/4/01.asp
Problème de vitesse sous Windows NT :
article 177654 :
http://support.microsoft.com/support/kb/articles/Q177/6/54.ASP?LNG=ENG&SA=PER
Modifications à effectuer suivant le système d'exploitation :
Windows 95 (toutes versions 0SR2.5 incluse) :
1. Mises à jour de la Base de registre :
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VXD\VREDIR]
"Start"=hex:00
"StaticVxD"="vredir.vxd"
2. Deux fichiers systèmes
Connu sur le serveur de Microsoft sous le nom VRDRUPD.EXE, vous devez exécuter cette mise à
jour qui modifiera deux fichiers : VREDIR.VXD et VNETSUP.VXD.
http://support.microsoft.com/download/support/mslfiles/Vrdrupd.exe
Windows 98 (toutes versions) :
1. Mises à jour de la Base de registre :
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VXD\VREDIR]
"NetClean"=hex:01
"DiscardCacheOnOpen"=hex:01
Windows NT WorkStation (Toutes versions < 4.0)
1. Mises à jour de la base de registre
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"UtilizeNtCaching"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters]
"UseWriteBehind"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Nbf\Parameters]
"MinimumT1Timeout"=dword:00000008
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanWorkStation\Parameters]
"UseOpportunisticLocking"=dword:00000000
Windows NT 2000 Workstation :
1. Mises à jour de la base de registre
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"UtilizeNtCaching"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Nbf\Parameters]
"MinimumT1Timeout"=dword:00000008
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanWorkStation\Parameters]
"UseOpportunisticLocking"=dword:00000000
Windows NT Server (Toutes versions confondues)
1. Mises à jour de la base de registre
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanWorkStation\Parameters]
"UtilizeNtCaching"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters]
"UseWriteBehind"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanServer\Parameters]
Locks opportunistic : un cas vécu
I have for a few months, suffered from EXTREME slowness using NT4SP4 file
server for a Paradox application running on Win98SE clients. (The
application runs fine on Novel 4.2 or a peer to peer network)
I followed all the instructions in the FAQ entitled TIP:PdoxWin:NT
Configuration:2000.06.09 but all to no avail.
I think this is because the section on how to turn off opportunistic locking
on your server is misleading. It reads :
***===============
***3. Tips
***===============
***1. Change the opportunistic locking on the NT server to false.
*** You may need to add settings to the Registry to do this.
*** In the
***
***HKEY_LOCAL_MACHINES\System\CurrentControlSet\Services\
*** LanmanWorkstation\Parameters
***section, change (or add) the UseOpportunisticLocking key
*** to a value of 0 (zero, decimal).
The registry setting which should be added is :
HKEY_LOCAL_MACHINES\System\CurrentControlSet\Services\
LanmanSERVER\Parameters\EnableOplocks=0 (DWORD)
I changed this, then rebooted and the speed of Paradox increased up to 20
times. One particular operation which took 8 hours 13 minutes yesterday, now
takes 28 minutes. Amazing.
Just thought I'd let you know, as I have struggled through various sources
of information for a long time to get this far.
