-
.Q.par Doesn’t Provide the Correct Result in the Segmented db.
Hey Everyone. .Q.par function is not giving the Correct partition in our Segmented Database.
for Example, It was giving the result, that the partition for 2021.01.01 was present in /nvme01/ {{directory_name}}/0/ location.
when checking using Find Command, The partition was actually present in this directory ( /nvme08/{{directory_name}}/6).
We have also verified all the partition are present only once in our Segmented Database.
We also Facing issue with .Q.chk function. When running this function,it takes more than 30 minutes. Even though it doesn’t completes its execution. Parallely we have checked whether it fills the partition with missing Tables. it doesn’t do that too.Did anyone face this kind of Problem.
Kindly Share the Ways to Resolve this Problem. Attached Snapshot FYR.
-
3 Replies
-
.Q.par doesn’t check where the partition is, only where it should be according to par.txt. It assigns the segments by taking the modulus of the date by the number of par.txt entries.
-
Yes there is a warning on: https://code.kx.com/q/database/segment/#considerations
“Partition data correctly: data for a particular date must reside in the partition for that date.“
-
Seems like a case when entries were added in par.txt from possibly 3 to 8 without moving the partitions to correct locations. Only way to fix this is to move all the partitions to right locations.
These all will be giving inconsistent results
`l `bv `L `a2 `par `dpts `dpt `dpft `dpft `dsftg `chk
Log in to reply.