I have a snaphot view on linux and trying to update it, but i'm getting error like this.
cleartool: Unable to access "/vobs/myvob/myfolderinvob": database timed out
Does anyone can suggest what to do.
Clearcase 7.1.2, Kubuntu 12.10 x86_64
That specific error message can appear because of a Lock Manager issue (on the Vob Server side).
From this doc:
The Lock Manager manages lock requests from any process that needs to access a VOB database.
Actually, there are only two of those:
db_server,
vobrpc_server,
There's only one lockmgr process per VOB server, no matter how many VOBs you have on the server.
And the Lock Manager has various limits that are defined when it's started, via the command line or via a registry value for file tables (the -f parameter), user tables (the -u parameter), or
queue tables (the -q parameter).
The -f parameter indirectly determines how many VOBs can be accessed on a system at any one time.
VOB databases have 7 files each (3 data files and 4 key files) in the VOB storage area db subdirectory.
The default -f value of 256 files means that there can be 36 VOBs (256 divided by 7) on a server without modification.
If you have more than 36 VOBs on a server and you haven't modified this, you might encounter problems such as poor end-user response while waiting for locks, and various error messages in the log file.
Try increasing the -f parameter to increase the size of the lockmgr process. There's no
practical limit to the size of the file table, but we recommend that you set the value to 7 times the number of VOBs you're going to have on the system.
The -u parameter determines the maximum number of db_server and vobrpc_server processes that can request locks from the Lock Manager.
Again, the default value is 256.
Typically, there's only going to be one active db_server process for each active client ClearCase command. This parameter essentially limits the amount of concurrent ClearCase activity, no matter how many VOBs are on the system. Again, you'll see poor end-user response and "lock manager is busy" errors if the -u parameter is set too low.
The -q parameter determines how many lock requests can be queued by the Lock Manager at any one time. The default is 1024.
Again, you'll see poor end-user response and "database timed out" messages in the log file if this parameter is set too low.
To resolve the problem, we recommend you increase the -q parameter to up to five times the value
of the -u parameter (although in actuality there's no upper bound), because the db_server process usually requests a lock for five database files in one request.
For more on how to tweak those values, see "Supplement to the Administrator's Guide about the Lock Manager".
For a Unix Vob server:
The ability to have different parameters for each VOB on the system as well as a locally-specified override for server-wide settings is now possible through use of a configuration file called vob_almd_params.
NOTE: Although it is possible to set up per VOB almd parameters, we recommend that instead you use only the per server wide settings in /opt/rational/clearcase/config/vob/db.
The vob_almd_params server wide configuration file is located in the /opt/rational/clearcase/config/vob/db directory and controls the settings for all VOBs on the host.
The vob_almd_params files in the individual VOB db directory (<vob-storage-dir>/db/vob_almd_params) will modify the settings for that individual VOB, rather than all VOBs on a host.
Note: The parameter values can be lower than the ones used in previous releases.
The syntax employed within the vob_almd_params file:
–u num –q num
Related
This is a follow on from op - Moving Vobs between Win and AIX
Due to the aix and win vob servers sharing resources (common CC reg & Common Admin PVOB on the Aix box) we need to amalgamate these vob servers onto the AIX server as a precursor to our ultimate move to new servers at CC8.
on the Win VOb Server we have locked the vob, run vob_siddump then a reformat dump of the vob.
Then using xcopy we copied the dumped vob.vbs from Windows to AIX vob server run the fix_prot on the new server.
But when we run the reformatvob -load it goes through it's steps Shows "Loader Done" then shows the following errors
Error from vob database /vobstore/vobs/vobname.vbs.
Error Trouble Opening the VOB Database /vobstore/vobs/vobname.vbs,
Error Trouble Loading versioned object base /vobstore/vobs/vobname.vbs.
Because of the shared registry is this due to the existing registry entry and we need to unregister and then rmtag before registering and tagging fresh or do we need to do anything further?
Clearcase logs on aix vob server show:
DB Log - Error process not running on registery specified hostname (old win vob server)
Vob Log - shows unix UID and GID messange and Warning unable to verify mount options in vob tag registry Clearcase Object not found
David, there are a few things you need to do here:
unregister the VOB and remove all the tags that refer to the old server
reregister and retag the vobs at the new location.
If you can't register the VOB, run fix_prot -r -root ... to reset the ownership and try again.
run vob_sidwalk to remap object ownership.
run it again with -recover_filesystem to reset container ownership. Alternatively run checkvob -pool -protections -fix -force {vob storage dir}.
The last step really needed to be started on the Windows side before this started. Essentially, you needed a sid dump file to turn into the map file that the sidwalk needs (unless you want to remap everything to the VOB owner...)
The complete procedure to follow is at Moving VOBs between Operating system types You may want to start fresh from there if you still have the VOB located in the old location.
I have a shared accde file on a network drive. Occasionally we will have an inconsistent state problem. The error message appears below. It seems to be associated with network connection interruptions for even one user. We have an example when a user unplugged the Ethernet and switched automatically to wireless and other examples where users have left the database open overnight, perhaps when a machine hibernates.
Once this happens the one user cannot work and no one can open the accde file. Other users who have the database open can continue to work.
After the problem occurs it remains until everyone closes the database. At that time it completes whatever recovery it requires and all users can get back in.
This was disruptive when we had six users in one room. Now we have 17 in two cities and a few work-from-home users. It's becoming intolerable.
The obvious answer is to move away from Access. We're working on it but it's a long way off. In the mean time I would appreciate any advice.
Is there a way to prevent the problem entirely?
Is there a VBA way to detect the problem in the instances that are not showing the error message?
Is there something I'm not thinking of?
What would you do?
Error message:
Microsoft Access has detected that this database is in an inconsistent state, and will attempt to recover the database. During this process, a backup copy of the database will be made and all recovered objects will be placed in a new database. Access with then open the new database. The names of objects that were not successfully recovered will be logged in the "Recovery Error" table.
The solution that Microsoft gives is Splitting the database, which just means to put the data elements on a shared server, and everyone has their own copy of the front end.
This might cause problems if that front end needs to be updated (e.g. additional forms). Details here:
http://answers.microsoft.com/en-us/office/forum/office_2007-access/microsoft-office-has-detected-that-this-database/3fb41c70-f7ba-41dd-a847-e62203071466?auth=1
Check the row count in the tables, the tables most likely have large amounts of data creating latency on the read and write queries, causing the locking.
Archive older data and keep the database small and neat, perhaps create referenced databases for archived information
I gather that your MS Access database is getting corrupt when up put it on a shared drive. A Microsoft Access database may get corrupt when in a multi- user environment. Here are the workaround that you can use in order to fix it.
Step 1: Run Command Prompt as Administrator
Click on the Windows icon and type Command Prompt. Then right-click on the Command Prompt and choose Run as administrator option.
Step 2: Execute Compact and Repair Database Command
In the command prompt window, type the following command and then press ‘Enter’.
msaccess <database file name> /compact
In the command, replace <database filename> with database path. For instance,
msaccess "C:\Program Files\Reports.mdb" /compact
This will start the process to compact and repair the faulty Access database file.
Otherwise, You can check out this thread for an alternative solution : https://dba.stackexchange.com/questions/71906/ms-access-mdb-ldb-database-corrupted/171275#171275
My issue is that I work from various systems yet require access to a single, large (50 Gb) database that is always up to date. If it were a smaller database, dumping and restoring the database onto the external disk would by fine, e.g. via $ pg_dump mydb > /path../db.sql to save it and then on the other computer use $psql -d mydb -f /path../db.sql to recover the data and so on...
In this case, however, that option will not work as I don't have 50 Gb of free space on both machines. So I'd like the files for this particular db to be on a single external drive.
How would I do this?
I've been using pg_cltcluster for this purpose, e.g.
$ cp -rp ax/var/lib/postgresql/9.1/main /media/newdest # move the data
$ pg_cltcluster 9.1 main stop # stop the postgres server (on ubuntu: add -- [ctl args])
$ /usr/lib/postgresql/9.1/bin/initdb -D /media/newdest # initialise instance in new place
(On ubuntu, pg_ctlcluster is used instead of pg_ctl to allow multiple db clusters and this should allow pg_ctlcluster 9.1 main start -- -D /media/newdest to replace the last line of code, I think)
I suspect this approach is not the best solution because a) it's not working at present after various tries and b) I'm not sure I'll be able to access the cluster from another computer.
Database software are designed to handle large datasets and moving your data around is a common task so I am baffled about why there is less info on this on the internet:
This question that basically says "don't use TABLESPACES to do it"
This one that just solves the permissions problem and links to a (useful) IMB page on the matter that talks about moving the entire setup, not just one database as I want to.
How to know an incoming sync packet is inteded for a particular vob?
multitool lspacket -l doesn't tell for which vob this is intended.
I have several incoming packets intended for my replica but when I import them using this command i am getting the below error:
C:\Program Files\IBM\RationalSDLC\ClearCase\var\shipping\ms_ship\incoming>multitool syncreplica -import sync_usal_unix_2012-11-29T23.00.17-05.00_2296
multitool: Error: Sync. packet C:\Program Files\IBM\RationalSDLC\ClearCase\var\shipping\ms_ship\incoming\sync_usal_unix_2012-11-29T23.00.17-05.00_2296 is not applicable.
Actually, multitool lspacket is the right command to check initially:
The OP vchitta initially thought:
The lspacket gave the below out put which shows that the intended replica name is correct but it doesn't reveal the VOB details.
multitool lspacket sync_usal_unix_2012-12-01T23.01.06-05.00_19957
Packet is: C:\Program Files\IBM\RationalSDLC\ClearCase\var\shipping\ms_ship\incoming\sync_usal_unix_2012-12-01T23.01.06-05.00_19957
Packet type: Update Packet fragment: 1 of 1
VOB family identifier is: 360ab8c4.661e11d3.a49e.00:01:80:a9:b5:ec
To which I argued:
Did you search '360ab8c4.661e11d3.a49e.00:01:80:a9:b5:ec' in the vob registry?
(or simply cleartool lsvob -l)
Is there any other Vob which would have the same uid?
See VOB objects and VOB replica objects.
Yes or no, this is your answer right there.
THE IBM documentation clearly mentions:
Each replica is a VOB, but the VOB object and VOB-replica object are different objects in the VOB database.
Specifically:
VOB object: The database has a single VOB object.
This object’s UUID is listed as the VOB family uuid in a lsvob –long listing.
VOB-replica object (or replica object): The database has a VOB-replica object for each of the VOB’s replicas.
This object’s UUID is listed as the Vob replica uuid in a lsvob –long listing.
The OP adds:
No.
No vob is having family identifier with the above UUID.
Now I am able to find which vob a packet is intended for with the help of family UUID.
I found this particular packet is for Platfom vob which I didn't replicated yet.
Original answer
See first "Packet is not applicable to any local replicas"
To verify that the host-name property of a VOB replica is wrong, enter the following command:
cleartool describe –fmt "%[replica_host]p\n"
replica:importing-replica-name#VOB-tag
For example:
cleartool describe –fmt "%[replica_host]p\n" replica:newyork#/vobs/tests
manhattan
If the host name is incorrect, use the chreplica command to change it. At the master replica of the importing replica, enter a chreplica command:
multitool chreplica –c "comment" –host new-host
replica:importing-replica-name#VOB-tag
For example:
multitool chreplica –c "change host name" –host brooklyn
replica:newyork#/vobs/tests
Updated replica information for "newyork".
Send an update packet to the other replicas in the family.
You can have multiple causes, as describes in this technote
Cause
The import command may have been run from a host other than the VOB server.
The hostname associated with the replica may have changed and MultiSite has not been updated.
The VOB server may have multiple host names and or multiple network cards and MultiSite is not properly configured to work with them.
Resolving the problem
For cause 1:
Make sure the syncreplica -import command is being run on the VOB server host.
The syncreplica -import command must be run on the VOB server host as it is a server operation.
For cause 2:
Check the hostnames associated with the replica and compare the outputs using the two commands below.
The VOB and the replica should show identical "host" output. If they do not, this is likely to be the problem.
Use the multitool chreplica -host command to resolve the problem.
Review the MultiSite Administrator's Guide on the topic of chreplica (multitool man chreplica) for more details.
cleartool lsvob -long <vob tag>
multitool lsreplica -long <replica-name>
For cause 3:
If the import is in fact being run on the correct server host, check to see how many hostnames that machine has.
Maybe the server has more then one network card, or several aliases.
If there is more than one name, make sure that the alternate_hostnames file exists.
It should contain each and every hostname the machine has, one per line.
Note: The alternate_hostnames file is supported on UNIX® and Linux® only.
I would like to know:
How to Load two vobs in two different views where both vobs are in different registry and vob servers in a single client windows machine?
Different registry??? I dont think thats possible, because in the first place the View will not be the same across different registry.
Different VOB server in the same registry is not an issue, just load it normally.
Maybe I misunderstood your problem.
You need:
to pick one registry server
declare (mktag and register) the other vob from the other registry server in the first one
make sure the global path of the other vob is accessible from your client and from the first vob server (Windows to Unix can work, with, for instance, Samba. But if your VOB server, the one that you pick, is a Unix one, it won't be able to access VOB managed by a Windows Vob server)
Note: the hard part is to mktag and register the other vob in your registry server: you cannot do it in command line, because it will try to modify some files in the vob storage (which your first registry server has no right to do)
You can however do it graphically:
launch ccadminconsole.msc
Select the 'Registry' section:
create a new VOB object