Section 5.0, PI Archives.
Now the objectives in this section is first we want to
explain how archives are filled, and
do what we call a shift after they fill up
completely. We want you to be able to create archives
using the PI SMT Plug-in, register
and unregister archives that way as well. Also, we will talk about forcing
a shift, how to do it, when to do it, when not to do it.
And we will also talk about setting a specific
Tuning Parameter to -- for example,
we have a nice automatic archive creation
and setting that we'd like to go over.
And also, an EditDays
option to, to specify how
long going back in time you can
edit your data. So, we will take a look at all those things. Now,
the, the first thing we should talk about is just
coming up with a good strategy. What would be a
useful way that your archives worked?
And again, let's just make sure there's no misunderstanding. The archives
is simply the name -- the word archive is what we use to describe
the online files that we use to
store PI data. These are the archive files that are created
during the installation, and it's
in these archives that we are storing
current data. It's typical in a system to have
dozens, if not hundred, of archive files sitting
around. And, of course, at some point, you are probably
going to back them up and store them away.
But, in, in general use,
the word archive does not refer to the things that are stored away,
they are talk...-- we are talking now about those things that are online
and currently used for storing current
data. So, what would be
a good configuration? What would be an ideal?
Well, ideally, we would want the archives
to be conveniently sized, not to be
too big so that you'd be, kind of, putting all your
eggs in one basket, so, if there is any kind of a problem,
and there are user errors that can result in problems. You know, we
do not necessarily want to put archives too
big, so that you'd loose too much data if there is the worst
case scenario. Also, we want
a, kind of a consistent and informative naming
policy, and by that, what I would mean is
a naming policy that, that gives you some clue as to what's in there.
You will notice, by default, those name I showed you, they are not
very useful. You'd normally have to
document separately, offline somewhere, what's actually in
them. So, it would be better if we had a better naming policy.
And, finally, we would, it would be
nice if you automatically created new archives as you needed
them. So that, you know, as long as you have enough free
disk same, it would be very convenient for the system manager
not to have to come in one day and find that
the data that he expected to be on line, is no longer on
line because we have done what we call a shift
on top of some older data. It would be nice, if instead,
the PI System allocated space as it
needed it, and created new archives automatically.
So this is what we would consider,
you know, effective strategy.
This strategy that I described in the last segment --
I am just kind of curious what value you would think that would
be to you. In, in class, that's what we do. We pause for a second. We ask
everybody, what value would that be? And we get a whole variety
of answers. So, here's some of the things that we suggest
would give you, you know, the value in having an efficient
archive system set up the way I just described.
First of all, you would not need to create archives manually,
as, as you could
be required if you did not have this set up the way we are
recommending. You, there's no data that's going to be
overwritten if you, you know,
if you leave the system. It will continue to generate
new data, new archives, and as long as
you do not run out of disk space you are in good shape. You are not going to overwrite
existing data. Be able to keep more data available
for users. Be easy to retrieve older
offline data when needed. That's, specifically when
you have backups that are stored off on disk
or tape somewhere. It's a lot easier to retrieve these
back if you have some kind of a good naming convention.
See, again, going back here,
let's pretend that this archive here has been backed up
along with its accompanying annotation file,
which we will describe more later. But, let's say that's the situation.
How do you know what's actually in there? Well,
unless you store some kind of a list
with that, or annotate your tape, you know, just
put a marker on it that explains what dates those are,
unless you do that, you really do not have any idea what's in there.
It's not very convenient to inspect those when they are offline.
So, if you do follow our recommendations,
it's a lot easier to retrieve older offline data,
simply because the naming convention will help
you identify the dates.
It's easy to identify which archive covers which period.
Undefined
simply looking at the data, much less trying to retrieve it
from being offline somewhere. It's a lot easier
to see which archives are, are which, and which ones
contain certain dates. So those two are kind of related.
This is going to be -- of course, the naming convention
makes it easier to retrieve the offline data,
'cause the naming convention tells you what's there.
So, and that, and that may, that may,
of course, make it easier as you are working with it on a regular basis,
on a day-to-day basis. So, with these things in mind,
we are going to go ahead and proceed to discuss how to implement these
features, and see how we can
configure a system to behave using those ideals
as I just described.
Section 5.1. Archive Sizing and Structure.
Now, it may be
obvious, but I want to point out that what's
stored in the PI archives is the real-time data.
So, again, maybe it's real obvious, but if
you take a look at what is stored
in our PIdat directory --
this is the archives, that's where we store the real-time
data. The Point Attributes,
the Point Database, is stored in PI Points. The digital
sate -- excuse me, the digital state sets are
stored in this file. So, again,
real obvious, but that's where we store the real-time data.
And, when we say, real-time, stime, time data, we are
talking about Events. Events are, you know, basically
something that consists of a timestamp,
a value, and a status. That's all going to go into this
file right here. It
is something that is designed -- or these archives are designed
to be contiguous. In other words, they
run right up to one, and then
pick up where the other one left off, and -- so, they are non-
overlapping time ranges. So, each one of these
will have a different range of time. And, I should
point out right now, that the numbering has got nothing to do with
the range of time. So, I have always
told our developers we should have called these, your know, Manny, Mo and
Jack, or some weird name that does not imply sequence,
because giving them these numbers implies there's
some kind of a sequence. But, if you will look at our shifting algorithm,
very quickly you will notice the naming and the sequence do not
have anything to do with each other. That's one of the reasons we
suggest using auto archive creation. It makes the
names a little easier to recognize what's in them.
And, then finally, these archive files can be
sized anywhere from two megabytes to two terabytes in size.
So, I chose the default in this case,
128 MB. Now, speaking of
sizing, that brings up the interesting issue -- what
size should you make these? And we covered that briefly during the,
the installation section. But,
again, we are suggesting that you go anywhere from
10 to 100 KB for each
tag. 10 to 100K. If you do the
math on that, that ends up being between
10 - 100 MB per 1,000 tags,
which is very close to -- well, it's, it's, it's,
it's, it's somewhat similar to what we had been recommending for years and years:
10 - 20 MB per thousand tags.
Now with the newer systems, we found we can go all the way up to 100 MB
per thousand tags without affecting
performance. And, if you do get bigger than that, well,
do not worry about it too much. It's only a
measurable decrease in speed, certainly not
anything worth reacting to.
So you should be fine even if you go a little bit above that.
But, we recommend to, 10 to, 10 to a, a
hundred KB per one tag, or for each tag,
for the sizing. The
archive receiving the current data is called the "Primary Archive."
If you remember when we looked at this in the System Management Tools, it was
listed as archive zero.
When that Primary Archive is full, it shifts
and another archive takes its place. It becomes the,
the Primary Archive. It's kind of a shift really
in focus. We are not actually, physically moving
anything anywhere. We will talk about that Shifting Algorithm
in a few minutes.