0

I'm working with a customer using the InterSystems cache' database environment and they are asking what's the best way to deal with the .pck file that's part of the database structure. When I attempted to research this to understand their ask, I came up short nearly every place on what this file is, where it's located, and how or why it's problematic.

any advice would be helpful

tom

DAiMor
  • 3,185
  • 16
  • 24
TW3
  • 3
  • 2
  • Maybe you mean LCK files? Because Cache does not have any PCK files. – DAiMor Nov 09 '17 at 07:54
  • I think you might be correct but what's throwing me off is that the cache.lck file is generated when the namespace and instance are at normal run-level and based on the Intersystems document indicates that the cache.lck file contains the security of who started the instance and mount directory. What I don't get is the customer characterizing that when they attempt to back up this file up, it takes an extraordinary amount to backup. The only thing I can come up with is that since the instance is frozen, maybe the cache.lck file is also frozen preventing a timely backup. Does this hold true? – TW3 Nov 11 '17 at 01:31

1 Answers1

1

Since we got that you talk about LCK file, it becomes more clear.
Well, lck file, is a kind of lock file, for databases in Caché. Which should be close to the mounted database (CACHE.DAT file) all the time when the system is running, preventing to use this database to write from another Caché instance. While Caché correctly shutdowns it is clear lck files created before.
While you touched backup theme for Caché Databases. I can say if lck files appeared to be backuped as well, something going wrong in a backup process. Depending on a way chosen to backup databases, you should not even have lock files existed during a backup process. Or you just should not backup it. While you mentioned freeze in comment, in this case lock files can still exist, and just have to copy only CACHE.DAT, it should be safe. But without freeze copy databases from working server quite dangerous, and nobody can guarantee that database will not have integrity errors.

DAiMor
  • 3,185
  • 16
  • 24