KR20040001692A - method for monitoring database by using hand-held device and computer-readable medium thereof - Google Patents

Abstract

PURPOSE: A method for monitoring a database by using a portable terminal, and a recording medium recorded with the same are provided to monitor a database in real time through a portable terminal a user possesses. CONSTITUTION: A database server(100) inputs data received from a database client(600) or transmits a work result to the database client(600) in response to a request of the database client(600). A socket server(200) executes data exchange between the data server(100) and a portable terminal(500) or between the data server(100) and the database client(600), and executes multi-process control. A database schema control server(300) refers to schema information and dictionary information of the data server(100) by using the socket server(200), and controls the data server(100). A wire/wireless interface module(400) executes communication between the socket server(200) and the portable terminal(500) or between the socket server(200) and the database client(600). The portable terminal(500) monitors the data server(100) through a wireless communication network. The database client(600) receives data or work commands from a plurality of users for transmitting the same to the data server(100), and receives the process result from the data server(100).

Description

Method for monitoring database by using hand-held device and computer-readable medium

The present invention relates to a database monitoring method using a portable terminal and a storage medium on which the method is recorded. More particularly, the state of the database can be monitored remotely using the portable terminal, and the database can be directly manipulated if necessary. A database monitoring method and a storage medium in which the method is recorded.

With the development of information and communication technology, the importance of database management is increasing. In a conventional database management system, the state of a database can be confirmed only at a fixed place such as a computer room. In other words, the administrator had to constantly monitor the state of the database.

In order to solve the above disadvantage, when a specific problem occurs in the database, a database management system for transmitting an SMS message or voice message to the administrator has been developed. However, even in this case, since the problem is merely communicated to the administrator, there is a problem in that it is necessary to directly connect to the database management system where the problem occurs in order to solve the problem. When the number of users is relatively small and the backup database is operating smoothly, there is a time gap between the administrator's problem occurrence and the action to be taken, so that the administrator can respond to the problem with sufficient time. However, if the type of problem is serious and the backup database is not running smoothly, there is not enough time between administrators to recognize the problem and take action.

Therefore, the present invention has been made to solve the above problems, the object of the present invention is to overcome the limitation of time and place, which is the biggest problem in database management, real-time database through the portable terminal possessed by the administrator To monitor.

Another object of the present invention is to enable a database administrator to solve a problem in real time through a portable terminal when a problem occurs in the database.

1 is an exemplary diagram showing a system for executing a database monitoring method using a portable terminal according to an embodiment of the present invention;

2 is a block diagram illustrating modules of a socket server, a database schema control server, and a client according to an exemplary embodiment of the present invention;

3 is a block diagram illustrating the logical components of each module of a database schema control server according to one preferred embodiment of the present invention;

4 is a block diagram illustrating the logical components of each module of a client-side module in accordance with one preferred embodiment of the present invention;

5 is an exemplary view showing a screen display in a portable terminal according to an embodiment of the present invention;

6 is a flow diagram illustrating the interrelationships between components of a system in accordance with one preferred embodiment of the present invention;

In order to achieve the above object, according to a preferred embodiment of the present invention, coupled to a database server and at least one portable terminal, in a method executed in a system for monitoring the state of the database server, Accessing, monitoring the database server, transmitting the monitoring result to the portable terminal, receiving a control command from the portable terminal to the database server, and receiving the received control command. A database monitoring method using a portable terminal including transmitting to a database server is provided. In the monitoring of the database server, at least one of schema information and dictionary information of the database server is analyzed to monitor the state of the database server. The transmitting of the monitoring result to the portable terminal may include transmitting status information of the database server to the portable terminal when the database server is abnormally operated. In addition, the control command is an SQL statement for solving the problem of the database server.

According to another aspect of the present invention, there is provided a recorded storage medium in which a database monitoring method using a portable terminal is implemented as a program in a computer readable form.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is an exemplary diagram illustrating a database monitoring system in which a database monitoring method using a portable terminal according to an embodiment of the present invention is executed.

Referring to FIG. 1, the database monitoring system includes a database server 100, a socket server 200, a database schema server 300, a wired / wireless interface module 400, a portable terminal 500, and a database client 600. Include.

The database server 100 inputs data received from the database client 600 in response to a request of the database client 600 or transmits a work result to the database client 600. At this time, the database client 600 requests a desired operation to the database server 100 using a structured English Query Language (SQL) statement. The database server 100 to be described herein is a UNIX-based database server, and in more detail, it is assumed that the database server of ORACLE company. However, this does not limit the database server on which the present invention will be implemented to a UNIX-based database server.

The socket server 200 performs data exchange and multi-process control of work commands, work results, etc. between the database server 100-the portable terminal 500 or the database server 100-the database client 600.

The database schema control server 300 refers to schema information and dictionary information of the database server 100 using the socket server 200 and performs control of the database server 100. Here, the dictionary information includes (1) the names of tables and views in the database, (2) the names and data types of columns (COLUMN) in the database tables, and (3) the privileges of users. .

The wired / wireless interface module 400 performs communication between the socket server 200 and the portable terminal 500 and the socket server 200 and the database client 600.

The portable terminal 500 monitors the database server 100 through a wireless communication network. The portable terminal 500 is a digital device capable of transmitting and receiving data and processing data. As a portable terminal, a PDA is preferable. The administrator may monitor the state of the database server 100 by using the portable terminal 500, and may control the database server 100 directly when a problem occurs.

The database client 600 receives data or a work command from a plurality of users and transmits the data or work command to the database server 100, and receives the processing result from the database server 100.

2 is a block diagram illustrating modules of a socket server, a database schema control server, and a client according to an exemplary embodiment of the present invention. 2, reference numerals of FIG. 1 are referred to.

Referring to FIG. 2, the socket server 200 supports multisharing of a database. For this purpose, a plurality of portable terminals 500 and a plurality of database clients 600 and a database server 100 may be used. Perform the connection. The socket server 200 includes a multi-process control module 210, a DB interface module 220, and a client packet communication module 230.

The multi-process control module 210 performs a function of controlling the processes requested from the plurality of clients 600.

The DB interface module 220 performs an interface between the DATABASE QUERY APPLICATION and the C ++ integration module (INTEGRATE MODULE).

The client packet communication module 230 performs packet unit communication with the portable terminal 500 and the database client 600.

Referring back to FIG. 2, the DB schema control server 300 monitors and controls the database server 100 by referring to schema information and dictionary information of the database server 100. The DB schema control server 300 includes a user control module 310, an object control module 320, a performance control module 330, and an additional information module 370.

The user control module 310 controls information related to all users of the database server 100.

The object control module 320 manages an object of the database server 100. Objects include Table, Tablespace, Index, Trigger, View, Key, Constraint, Default, Rule, User-Defined It includes a user-defined data type and a stored procedure.

The performance control module 330 manages memory, disks, and various statistical data. In particular, the performance control module 330 detects an SQL statement that may cause or may cause a problem among the SQL statements residing in the memory of the database server 100, and detects a result of the detection of the portable terminal 500 or the database client ( 600). In some cases, the performance control module may directly solve the problem by removing the above-described SQL statement.

The additional information module 370 manages additional information other than memory, disk, and statistics of the database server 100 managed by the performance control module.

Referring back to FIG. 2, the client-side module mounted in the portable terminal 500 includes a plurality of viewer modules, and transmits a monitoring result of the database server 100 from the database schema control server 300. Received and displayed through the display built in the portable terminal 500. If a problem occurs, the administrator may solve the problem occurring in the database server 100 by inputting a control command, that is, an SQL statement in the SQL input window. The client side module is composed of a user module 510, an object viewer module 520, a performance viewer module 530, and a command module 540.

The user module 510 displays information related to all the users who are connected to the database server 100. Connection information (who is connected), database user accounts, and privileges are displayed as user related information.

The object viewer module 520 displays information related to the object of the database server 100. The object related information may be displayed based on a schema, an object type, or a database file.

The performance viewer module 530 displays information related to the operational performance of the database server 100. Memory, disks, statistics and additional information are displayed as performance related information.

The command module 540 receives a database control command from an administrator and transmits the received control command to a database client 600 at a remote location.

3 is a block diagram illustrating logical components of each module of a database schema control server according to an exemplary embodiment of the present invention. 3, reference numerals of FIGS. 1 to 2 are referred to.

Referring to FIG. 3, the user control module 310 may include a current user connection 311, a user 313 currently in use, a user 315 currently waiting, a user block 317 in use, and a user detail-hit ratio ( 319).

The current user connection 311 collects connection information about a user currently connected to the database server 100 from corresponding schema information or dictionary information. The collected connection information includes SID, schema, OS user, terminal, program in use, and login time. The collected information is transmitted to the portable terminal 500 for display.

The user 313 currently in use collects information about a user who is being performed by the database server 100 from a user connected to the database server 100 from the schema information or dictionary information.

The currently waiting user 315 collects information about the user waiting for the requested job among the users connected to the database server 100 to be executed in the database server 100 from corresponding schema information or dictionary information. The currently waiting user 315 may collect the number of waiting users through the following SQL statement.

SELECT COUNT (*)

FROM session_wait dictionary

WHERE EVENT NOT IN (specific ROW in the SESSION_WAIT dictionary)

If the number of waiting users is greater than the preset limit value, the currently waiting user 315 determines that a problem has occurred in the database server 100.

The user block 317 in use collects information about connections blocked by other users from corresponding schema information or dictionary information. The total number of blocked connections can be collected through the following SQL statement.

SELECTCOUNT (*)

FROM Session Dictionary

WHERE LOCKWAIT IS NOT NULL

If the number of blocked connections is greater than the preset limit, the user block 317 in use determines that a problem has occurred in the database server 100.

The user detail-hit ratio 319 collects the leading sessions (LEADING SESSIONS) sorted based on memory usage from corresponding schema information or dictionary information. The information collected based on the amount of memory in use is divided into 'user name', 'SID', 'serial number', 'status', 'pga memory', 'uga memory' and 'size of total memory used'. It is displayed on the portable terminal 500. The user detail-hit ratio 319 may collect information about leading sessions arranged based on memory usage through the following SQL statement.

SELECT username, SID, serial number, status, pga memory, uga memory, total amount of memory in use (= pga memory + uga memory)

FROM session statistics dictionary, session dictionary, statistics name dictionary

WHERE constraint

ORDER BY Total amount of memory in use

Referring back to FIG. 3, the object control module 320 includes library cache object usage 321, buffer pool object summary 323, memory connection object details 325, and object detector analysis 327.

Library cache object usage 321 collects the contents of the library cache. The contents of the library cache collected are 'owner', 'object name', 'type', 'shareable memory', 'LOADS', 'execute', 'LOCKS', 'pins' , 'KEPT' is displayed in the portable terminal 500 in the order. Using the library cache object 321 may collect information about the contents of the library cache through the following SQL statement.

SELECT owner, object name, format, shareable memory, load, execute, lock, pin, hit

FROM database_object_cache

ORDER BY type

The buffer pool object summary 323 collects information about tables and indexes located in the buffer pool BUFFER POOL of the database server 100. Information about the collected tables and indexes is displayed on the portable terminal 500 in the order of 'object format', 'buffer pool', and 'number of objects'. The buffer pool object summary 323 may collect the number of tables and indexes through the following SQL statement.

SELECT segment_type, buffer_pool, COUNT (*)

FROM DBA_segment

WHERE constraint

GROUP BY segment_type, buffer_pool

ORDER BY segment_type, buffer_pool

The memory connection object detail 325 collects detailed information about an object to which the user is currently connected. The detailed information about the object is displayed on the portable terminal 500 in the order of 'owner', 'object name', 'type', and 'user being connected'. The memory access object detail 325 may collect detailed information about an object currently accessed by the user through the following SQL statement.

SELECT owner, object name, format, user name

FROM session dictionary, access dictionary

WHERE constraint

ORDER BY owner, object, username

The object inspect analysis 327 collects detailed information about the object currently being used and the extent currently used by the object. Detailed information about the object and its extents can be found in the following order: 'owner', 'object name', 'object type', 'extent', 'limit', 'percentage / limit'. It is displayed at 500. The object inspector 327 may collect detailed information on an object currently being used and an extent currently used by the object through an SQL statement as follows.

SELECT owner, object name, object type, extent, limit, percentage / limit

FROM DBA_segment dictionary

WHERE constraint

ORDER BY owner, object name, object format

Referring back to FIG. 3, the performance control module 330 may include a buffer cache hit rate 331, a library cache hit rate 333, a row cache hit rate 335, a memory sort rate 337, and a redo log space latency. (339), SQL Net Traffic (341), Shared Pool Memory Details (343), Tablespace & Datafile I / O (345), DBWR Statistics (347), Rollback Segment Status (349), Latch Session Wait (351) Transaction details 353.

The buffer cache hit ratio 331 collects the buffer cache hit ratio BUFFER CACHE HIT RATIO of the database server 100 from corresponding schema information or dictionary information. The buffer cache hit is a ratio of how often the database server 100 reads data from memory corresponding to a request for data of a user or process. That is, the higher the ratio of reading the data stored in the memory, that is, the higher the hit ratio, the more the operation of reading the data from the disk can be omitted, which means that the processing performance of the database server 100 is higher. On the contrary, a low hit ratio means that the database server needs to read data frequently, so the processing power of the database server is low. The buffer cache hit ratio 331 is calculated as a ratio of how often the data request from the memory has been met as compared to the physical requirement of the data from the disk. The buffer cache hit ratio 331 may calculate a ratio of how often the data request from the memory is met and whether the buffer cache hit ratio is physically met from the disk through the following SQL statement.

SELECT 100-100 * (Physical Read / Import DB Block + Matching DB Block)

FROM System Statistics Dictionary

Rows to read during WHERE system statistics dictionary

If the calculated buffer cache hit ratio is smaller than the preset limit value, the buffer cache hit ratio 331 determines that a problem has occurred in the database server 100.

The buffer cache hit ratio 331 may calculate the buffer cache hit ratio of the major sessions (LEADING SESSIONS) classified based on memory usage through the following SQL statement.

SELECT username, seed, serial number, status, machine, O / S ID, logon time, BLOACKED, SECOND IDEL, HIT RATIO

FROM session dictionary, session_IO dictionary, processor dictionary

WHERE constraint

ORDER BY username

The library cache hit ratio 333 collects the library cache hit ratio LIBRARY CACHE HIT RATIO of the database server 100 from corresponding schema information or dictionary information. LIBRARY CACHE HIT is a ratio of how often the database server 100 reads a request for PARSED SQL CODE AND DEFINITIONS from memory from a user or process. That is, the higher the ratio of reading the analyzed SQL code and definition stored in the memory, that is, the higher the hit ratio, the higher the processing performance of the database server 100 because the SQL statement analysis operation can be omitted. On the contrary, a low hit ratio means that the SQL server and definitions analyzed from disk must be frequently analyzed, which means that the processing performance of the database server is low. The library cache hit ratio 333 calculates how often it meets the requirements for the SQL code and definitions analyzed from memory as a ratio against the actual analysis operation. The library cache hit ratio 333 may calculate a ratio in preparation for a substantial analysis operation of how often the memory code and definition requirements are satisfied from memory through the following SQL statement.

SELECT 100- (RELOAD / PIN)

FROM Library Cache Dictionary

If the calculated library cache hit ratio is smaller than the preset limit value, the library cache hit ratio 333 determines that a problem has occurred in the database server 100.

The row cache hit ratio 335 collects the row cache hit ratio ROW CACHE HIT RATIO of the database server 100 from corresponding schema information or dictionary information. The row cache hit ratio is a percentage of how often the database server 100 has satisfied the request for dictionary information from memory and how often it has met from disk. The row cache hit ratio 335 may be calculated using the following SQL statement as compared to how often the request for dictionary information is satisfied from memory or how often from disk.

SELECT 100-((Import failed) / (Import successful + Import failed) * 100)

FROM hangcache dictionary

If the calculated row cache hit ratio is smaller than the preset limit value, the row cache hit ratio 335 determines that a problem has occurred in the database server 100.

The memory sort ratio 337 collects a memory sort ratio of the database server 100 from corresponding schema information or dictionary information. The memory sort ratio 337 is a ratio of how often the database server 100 performs a memory sort operation in comparison to a disk sort operation. The memory sort ratio 337 may calculate the ratio of how often the memory sort operation is performed compared to the disk sort operation through the following SQL statement.

SELECT 100 * Memory Sort / (Memory Sort + Disk Sort)

FROM System Statistics Dictionary

If the calculated memory sort ratio is greater than the preset limit value, the memory sort ratio 337 determines that a problem has occurred in the database server 100.

Redo log space wait time 339 collects the sum of cumulative time (cumulative time) that processes have to wait to allocate space in the redo log buffer (REDO LOG BUFFER) from the corresponding schema information or dictionary information. The redo log space waiting time 339 may calculate the redo log space waiting time through the following SQL statement.

SELECT REDOREQUEST, REDOSIZE, REDOENTRY ..

FROM System Statistics Dictionary

WHERE constraint

If the calculated redo log space waiting time is larger than a preset limit value, the redo log space waiting time 339 determines that a problem has occurred in the database server 100.

The SQL Net traffic 341 can calculate the cumulative amount of data sent to the database client 600, the cumulative amount of data received from the database client 600, and the cumulative number of messages sent to the server and the response from the corresponding schema information or dictionary information. Collect.

The shared pool memory detail 343 collects the contents of SHARED POOL MEMORY of the database server 100 from corresponding schema information or dictionary information. Shared pool memory is a term used in an Oracle database server, but in other types of database servers, the descriptions herein will be easily understood assuming that the memory having the same function as the shared pool memory is shared pool memory. The shared pool memory detail 343 may calculate the contents of the shared pool memory through the following SQL statement. The calculated contents of the shared memory may be displayed through the display means of the portable terminal 500.

SELECT name, byte, percentage used, size

FROM SGA Statistics Dictionary, SGA Dictionary

WHERE constraint

ORDER BY Used Percentage

The tablespace & datafile I / O 345 collects the I / O of the tablespace (TABLESPACE) and the datafile (DATAFILE) from the corresponding schema information or dictionary information. I / O includes PHYSICAL READ, PHYSICAL WRITE, BLOCK READ, BLOCK WRITE, READ TIME, and WRITE TIME. The tablespace & datafile I / O 345 can calculate the I / O of each tablespace through the following SQL statement.

SELECT tablespace name, physical read sum, physical write sum, physical block read sum, physical block write sum, read time sum, write time sum

FROM datafile dictionary, file statistics dictionary, DBA_data_file dictionary

WHERE constraint

GROUP BY table space name

ORDER BY physical read sum

In addition, the tablespace & datafile I / O 345 can calculate the I / O of each datafile through the following SQL statement.

SELECT data file name, table space name, physical read sum, physical write sum, physical block read sum, physical block write sum, read time sum, write time sum

FROM datafile dictionary, file statistics dictionary, DBA_data_file dictionary

WHERE constraint

ORDER BY physical read sum

The DBWR statistics 347 collects statistics of a database write process (DBRW) of the database server 100 from corresponding schema information or dictionary information. DBRW is one of the essential processes of the Oracle database server. The required processes are SMON (SYSTEM MONITOR), PMON (PROCESS MONITOR), DBRW (DATABASE WRITER), LGWR (LOG WRITER), and CKPT (CHECK POINT). Although DBRW is a term used to refer to an essential process of an Oracle database server, it is easily understood that DBRW is assumed to be a process that performs the same function as DBRW in other types of database servers. The DBWR statistics 347 may calculate statistical information about the database writing process through the following SQL statement. Statistical information about the calculated database writing process may be displayed through the display means of the portable terminal 500.

SELECT name, value

FROM System Statistics Dictionary

Rows related to WHEREDBRW

ORDER BY name

The rollback segment state 349 collects an attribute PROPERTY associated with the list of rollback segments from corresponding schema information or dictionary information. The rollback segment state 349 may calculate attributes related to the list of rollback segments through the following SQL statement. Attributes related to the calculated list of rollback segments may be displayed through the display means of the portable terminal 500.

SELECT Name, SHRINKS, EXTENDS, Getts, GETS, WAITS, Write, WRITES, EXTRACTS, Rollback Segment Size, Status

FROM rollback statistics dictionary, rollback name dictionary

WHERE constraint

The latch session wait 351 collects detailed information about a session specifically waiting for a latch request from corresponding schema information or dictionary information. The latch session wait 351 may calculate detailed information about a session waiting for a latch request through the following SQL statement. Detailed information regarding the session waiting for the latch request may be displayed through the display means of the portable terminal 500.

SELECT username, SID, serial number, latch name, event, parameter text 1, parameter 1, parameter text 2, parameter 2, sequence number, wait time, status

FROM session_wait dictionary, session dictionary, latch name dictionary

WHERE constraint

Transaction details 353 manage the details of transactions.

Referring back to FIG. 3, the additional information module 370 may include a CPU reading session 371, a memory reading session 373, an I / O reading session 375, a session limit 377, a network contention 379, Database link traffic 381, global redo statistics 383, and parallel query slave details 385.

The CPU reading session 371 collects user information of a main session that occupies a lot of CPU resources of the database server 100 from corresponding schema information or dictionary information. The CPU reading session 371 can calculate the user information of the main session that occupies a lot of CPU resources through the following SQL statement. The user information of the main session occupying a large amount of CPU resources may be displayed through the display means of the portable terminal 500.

SELECT session SID, session serial number, user name, CPU SECONDS

FROM session statistics dictionary, statistics name dictionary

WHERE constraint

The memory reading session 373 collects information about the main session of the currently allocated memory.

I / O reading session 375 collects information about the main sessions sorted by I / O from corresponding schema information or dictionary information. The I / O reading session 375 may calculate information about the main session sorted by I / O through the following SQL statement. It can be displayed through the display means of 500.

SELECT username, SID, serial number, status, machine, physical read sum, physical write sum, total I / O

FROM session statistics dictionary, session dictionary, statistics name dictionary

WHERE constraint

Session limit 377 manages the limits on sessions.

The network contention 379 collects all kinds of waits generated in the database server 100 and information related to waits occurring in the network from corresponding schema information or dictionary information. The network contention 379 may calculate all kinds of waits occurring in the database server 100 and information related to waits occurring in the network through SQL statements as follows.

SELECT Total Network Standby, Total Standby, Network Standby Percentage

FROM system_event dictionary

WHERE constraint

The database link traffic 381 is the total amount of data sent from the database server 100 to the remote server (THE ACCUMULATED TOTAL OF BYTES SENT FROM THE SERVER TO REMOTE SERVER), and the total amount of data received from the remote server RECEIVED FROM REMOTE SERVER) and the total number of messages sent and received between the database server 100 and the remote server are collected from the corresponding schema information or dictionary information.

The global redo statistics 383 collects information related to a redo log file from the corresponding schema information or dictionary information. The global redo statistics 383 may calculate information related to the redo log file through the following SQL statement.

SELECT name, value

FROM System Statistics Dictionary

WHERE constraint

The parallel query slave details 385 collects statistical information related to the parallel query from the schema information or the dictionary information. The parallel query slave details 385 may calculate statistical information related to the parallel query through a SQL statement as follows.

SELECT statistics, values

FROM parallel query_system stats dictionary

WHERE constraint

ORDER BY stats

4 is a block diagram illustrating logical components of each module of a client-side module according to a preferred embodiment of the present invention.

Referring to FIG. 4, the user module 510 includes a current user 511, a DB user account 513, and a right 515.

The current visitor 511 displays information about a user currently connected to the database server 511.

DB user account 513 displays information about the database user account.

Authority 515 displays information about the authority of the database user.

Referring back to FIG. 4, the object viewer module 520 includes a schema browser 521, an object type browser 523, and a DB file browser 525.

The schema browser 521 is a browser for reading information of a database based on a schema. When the user selects a specific table, information on the selected table is displayed.

The object type browser 523 is a browser for reading information of a database on the basis of an object. When the user selects a specific object, information related to the selected object is displayed.

The DB file browser 525 is a browser for reading the information of the database based on the data file. When the user selects a specific data file, information related to the selected data file is displayed.

Referring back to FIG. 4, the performance viewer module 530 includes a memory / SQL 531, a disk 533, and statistics 535.

The memory / SQL 531 is a browser capable of reading SQL statements stored in the memory of the database server 100. The information displayed includes SQL statements, execution counts, and load times.

The disk 533 is a browser that can browse information about the disk of the database server 100.

The statistics 535 are browsers that can browse various statistical information of the database server 100.

Referring back to FIG. 4, the additional information module 540 is a browser that can view additional information about the database server 100.

The SQL processing module 550 receives an SQL statement from a user and transmits the input SQL statement to the database client 600.

5 is an exemplary view showing a screen display in a portable terminal according to an embodiment of the present invention.

Referring to FIG. 5, the screen 700 includes a connection 701, an account 703, a permission 705, a schema 707, an object 709, a database file 711, a memory 713, and a disk 715. ), Statistics 717, additional information 719 icons, and SQL input window 721 are displayed.

The icons 701 to 719 displayed on the screen 700 are linked with each component described in FIG. 4, and accordingly, when the user selects each icon, the corresponding component is driven. The SQL input window 721 displayed on the screen 700 displays the SQL statement input from the user, and transmits the SQL statement to the database client 600 when the user inputs a transfer command.

6 is a flow diagram illustrating the interrelationships between components of a system in accordance with one preferred embodiment of the present invention.

Referring to FIG. 6, the database schema control server monitors a state of a database server through schema information and dictionary information, and transmits a monitoring result to at least one portable terminal connected through a socket server. If a problem occurs in the database server, the administrator who recognizes the problem through the portable terminal may solve the problem by inputting a control command through the portable terminal or the database client connected to the database server. Here, the control command is a SQL statement, it is preferable that the SQL statement that can delete or suspend the process or query causing the problem.

Therefore, the present invention is not limited to the above embodiments, and many variations are possible by those skilled in the art within the spirit of the present invention.

As described above, according to the present invention, in order to overcome the limitation of time and place, which is the biggest problem in database management, it is possible to monitor the database in real time through the portable terminal possessed by the administrator. In addition, when a problem occurs in the database, the database manager may solve the problem occurring through the portable terminal in real time.

Claims (5)

A method coupled to a database server and at least one portable terminal, the method executed in a system for monitoring a state of the database server, Accessing the database server; Monitoring the database server; Transmitting the monitoring result to the portable terminal; Receiving a control command from the portable terminal to the database server; And And transmitting the received control command to the database server. The method of claim 1, Monitoring the database server, And monitoring at least one of schema information and dictionary information of the database server to monitor the state of the database server. The method of claim 1, The step of transmitting the monitoring result to the portable terminal, And when the database server operates abnormally, transmitting status information of the database server to the portable terminal. The method of claim 3, The control command is a database monitoring method using a portable terminal, characterized in that the SQL statement for solving the problem of the database server. The recorded storage medium in which the database monitoring method using the portable terminal of any one of Claims 1-4 was implemented by the program of the computer-readable form.