arunvarman
New Member
hi i daily activities what are the main monitoring activities that has to been done using promon pls list i am using 9.1d progress db
monitoring the progress db
- Thread starter arunvarman
- Start date
arunvarman
New Member
ok sir for open edge what is the main monitoring activities that as to be followed using promon
TomBascom
Curmudgeon
It sounds like someone is trying to put together a training syllabus. Or perhaps fill out an interview questionnaire?
The first place to start would be the manuals. They are all on progress.com. I have not committed the link to memory but the search box usually turns them up when I'm hunting for something. The internet is funny that way.
Having said all of that -- if you are routinely using PROMON for "daily activities" you're probably doing something wrong. Or you have just arrived at a site that has never had a competent DBA present.
PROMON is sometimes useful for unstructured troubleshooting. Not so good for routine tasks.
The first place to start would be the manuals. They are all on progress.com. I have not committed the link to memory but the search box usually turns them up when I'm hunting for something. The internet is funny that way.
Having said all of that -- if you are routinely using PROMON for "daily activities" you're probably doing something wrong. Or you have just arrived at a site that has never had a competent DBA present.
PROMON is sometimes useful for unstructured troubleshooting. Not so good for routine tasks.
Rob Fitzpatrick
ProgressTalk.com Sponsor
I can only echo what has already been said here. Promon (or any other monitoring tool like Fathom Management) will give you data. There is a big difference between having data and having useful information and the knowledge and ability to act on it.
Promon will show you lots of things: buffer hits, writes by APW, checkpoint length, record waits, BI size; and hundreds if not thousands of other metrics. If you don't know what the buffer pool is, what an APW does, what a checkpoint is, what a record wait is, or how the BI file is used, does any of that data help you? Does it tell you which of those data points are interesting and which may indicate a problem? Does it tell you what to do about a problem if you find out you have one? No.
All things being equal, badly-configured databases will exhibit more problem behaviours than databases that are well-configured and tuned. If you have a badly-configured database, your time is better spent improving it than monitoring it to see if the problems continue. (They will.)
But before you can do any of that you need to understand how the database works. You need to know how to plan to deploy it, how to create it, how to configure it, what its various components and processes are and how they work, and how it interacts with other parts of the platform and the application environment (4GL clients, SQL clients, the OS memory manager, file system, network subsystem, and scheduler, etc.).
There is lots of good information available; some high-level and foundational, some detailed and highly technical. There are no shortcuts to learning. You must be willing to invest significant amounts of time and effort. Start at the beginning: download the documentation set for your Progress version.
Read the Installation and Configuration manual.
Read the Basic Database Tools manual.
Read the Database Design Guide.
Read the Database Administration Guide.
You will be glad you did.
Promon will show you lots of things: buffer hits, writes by APW, checkpoint length, record waits, BI size; and hundreds if not thousands of other metrics. If you don't know what the buffer pool is, what an APW does, what a checkpoint is, what a record wait is, or how the BI file is used, does any of that data help you? Does it tell you which of those data points are interesting and which may indicate a problem? Does it tell you what to do about a problem if you find out you have one? No.
All things being equal, badly-configured databases will exhibit more problem behaviours than databases that are well-configured and tuned. If you have a badly-configured database, your time is better spent improving it than monitoring it to see if the problems continue. (They will.)
But before you can do any of that you need to understand how the database works. You need to know how to plan to deploy it, how to create it, how to configure it, what its various components and processes are and how they work, and how it interacts with other parts of the platform and the application environment (4GL clients, SQL clients, the OS memory manager, file system, network subsystem, and scheduler, etc.).
There is lots of good information available; some high-level and foundational, some detailed and highly technical. There are no shortcuts to learning. You must be willing to invest significant amounts of time and effort. Start at the beginning: download the documentation set for your Progress version.
Read the Installation and Configuration manual.
Read the Basic Database Tools manual.
Read the Database Design Guide.
Read the Database Administration Guide.
You will be glad you did.