In this video I'll be checking my PI Data Archive
for a lot of common problems that it might be having with its
archiving functions. Archiving is a very important part of
the PI System and maintaining its health and
detecting problems are critical roles of a PI administrator.
If archiving isn't working properly,
interfaces may be unable to write
data and data could be inaccessible to
clients or you could be losing data or suffering from poor performance.
Here in PI System Management Tools,
the first thing to check to ensure archiving health
is here in Operation, PI Services.
I'm checking to make sure that the
archive subsystem is running. If it's not running,
it may have crashed or it was stopped or
didn't start properly. If it wasn't already
running, I could right click here and attempt to start it.
Now if I tried to start it and it's
still unable to start, I may have a corrupt or missing
primary archive or there could be problems with the
service or the machine resources.
The next check to do regarding archive health
is in the archives menu. If
your archive subsystem isn't running, this page doesn't load any
archives. And there will be an error printed down here
in the session record when we open the screen.
Here if we are running PI
System Management Tools 2015 or later,
we can see that my archive drive has lots of free space.
If you are running a version of PI System Management
Tools before 2015, the archive
disk space won't be displayed here. So we'll have to use
Windows Explorer. And here we can also
see that my archive drive has lots of free space.
The next check is to make sure
that I have a primary archive that isn't
full. This archive is our primary and I can tell because it has a
fixed start time with an end time of current time.
And I can see here that it still has
room in it.
Another problem we might see here is an archive
gap. I don't have any archive gaps and we can see
that each archive's end time is right up against the next
archive's start time. But if you do have an archive
gap, or a space between two archive files,
a line in System Management Tools will show you that you have an
archive gap and it will show information about
when that archive gap starts, stops and its total
length. This is important because any data
sent to a time period without an available registered archive
will be lost. Also any data sent to a time
period before the first archive will also be lost.
So if I was expected to receive any
data before my first archive starts, I would need
to create some new older archives.
The next checks are in the snapshot and archiving statistics menu.
I'll start by looking at my archive statistics.
So I'll choose to only show those statistics
by filtering here.
Here my archiving
flag is 3. Before version
3.4.395 or PI Data Archive 2015,
0 meant archiving was
turned off and 1 meant archiving was turned on.
As of version 3.4.395, the PI Data Archive
supports future data. So the archiving flag
can also show a value of 2 to
say that future data archiving is on or 3 to show that
future data archiving is on and historical
archiving is on. Check for the version information here
if you aren't sure about your system.
If your archiving flag is 0 or 2,
you may be having problems with your primary archive's
integrity or you could be having problems with the archiving
service that we already checked or you may have a failed
archived shift that you haven't recovered from yet.
If you do have a failed archive shift, this
flag shows a 1. Mine is a 0
so we know that my last archive shift was a success.
My archive loaded flag is also 1
to show that I have a primary archive loaded into the
archive subsystem.
The last thing on this page is in the
archive events counter. If archiving is
enabled, and we have data being sent to our PI Data Archive,
this number should be increasing when I hit refresh.
If you want reference material for
any of these statistics,
you can find their sections in our PI Server 2015 guide or by
searching for them in our PI Live Library.
Next up is the snapshot statistics.
Filtering by snapshot, we can see events sent
queue and events in queue. Data gets sent
and goes through the event queue before it reaches the archive
files. So if events in queue is low and not
growing, but events sent to queue is growing,
that means the data is likely flowing
through our event queue into the archive files.
If your event queue has corruption in it or your
PI Data Archive's archiving flag is turned off for one of the reasons we already discussed,
data could be stuck in your queue
and events in the queue will likely grow until the problem is
solved. We've confirmed archiving
is already working. So a build-up in events here
would likely indicate corruption in the event
queue.
My number of queue files is 2 and
the healthy number of event queue files will be 1 if your PI Data Archive
doesn't support future data. But it will be 2 if your PI Data Archive
does support future data. If you have more than
this amount, there is likely unarchived events
sitting in the excessive amounts of queue files.
More information about these statistics is also searchable
in our Live Library.
If you've checked these things
and are still are unable to read or write to particular
archives, it's possible that you have corruption in one or more of
your archive files. Here in the message
log, we could get errors and warnings that
would indicate archive file corruption.
For example I do have a piarchss
message informing me of a failed user query.
Now scrolling to the rest of the message, I can
see that it is due to a record header version mismatch.
Messages like this are indicative of
archive file corruption. Other messages that indicate
archive file corruption also include but aren't
limited to these in KB 2367OSI8.
If we do suspect an archive of being corrupt, we can analyze
it for errors by running a diagnostic tool from the command prompt.
Let's say that writing to this
archive, we get one of the errors from
KB 2367OSI8. To
check for corruption, we first have to unregister it,
keeping in mind that this will create an archive gap.
And now we can open the command
prompt as administrator
and navigate to our
% PIServer %
slash adm environment variable using the
/d flag. We'll us the program
PIDIAG and the option ARCHK
for archive check. And then we'll type in
the file path to the archive file that I just unregistered
and want to check for corruption.
I'll send the
output to a text file on my D drive so I can analyze it.
While this is running, this will print all the results of the archive check to the
text file I specified. So when I navigate to the
D drive and open that file,
we'll see the results of the archive check. If the archive check is
complete, we'll see the summary at the bottom and
we can tell that there is 0 errors with 0 warnings.
So the consistency check will report a success,
indicating that there is no problems with this archive.
Once we know it's healthy, it's important to register it again to make sure
we keep archive gaps to a minimum.
Back on my D drive, I have an
archive to use as an example of a corrupt archive.
So back in the command prompt,
I'll run the same PIDAIG ARCHK
command. But this time
D: PISERVER2_EXAMPLE
and send it to
a different text file.
This is going to print all the messages to the text file I specified again.
Once the archive check is complete, we can go
into the text file we created to see all the error messages
that archive check produces. And at the bottom
we can see how many error messages there are
and the overall health status of our archive file. Some
events that used to be in this archive file may be
lost, but it's possible to turn this into a healthy
archive file again through a procedure
called reprocessing. So far in this video
we confirmed that our PI Data Archive is successfully
archiving data by inspecting the most common
places where we'd run into archive problems.
In the next video I'll be reprocessing archives
to clear corruption but also to merge archive
files or to split larger archives into different
time periods or smaller file sizes.