Presentation is loading. Please wait.

Presentation is loading. Please wait.

Getting Started With Progress SQL-92 Sébastien Haefelé, SQL92 Product Advocate The Progress Company.

Similar presentations


Presentation on theme: "Getting Started With Progress SQL-92 Sébastien Haefelé, SQL92 Product Advocate The Progress Company."— Presentation transcript:

1 Getting Started With Progress SQL-92 Sébastien Haefelé, SQL92 Product Advocate The Progress Company

2 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 2 Goals n Get basic guidelines to start and configure a SQL92 servers n Properly manage privileges in your SQL92 database n Understand record locking behavior, versus transaction isolation levels with the SQL92 engine n Increase performances while accessing the SQL92 database

3 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 3 Agenda n SQL92 servers administration –Client-server architecture –Startup parameters –Best practices to start SQL92 DB servers: n Before 9.1d n With 9.1d –SQL server architecture n Database management n SQL92 and transactions n SQL92 and performances n Some Successes

4 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 4 SQL Servers Client Server Overview SQL & 4GL Broker SQL client 4GL client Shared Memory Database 4GL Servers 4GL client SQL client

5 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 5 Servers Startup Parameters n DB server performance parameters –-B, -L, -n, -spin, etc. n DB server internationalization parameters : –-cpcase, -cpcoll, -cpstream, etc. n DB server statistics parameters : –-usercount, -baseindex, etc. n DB server “network” parameters : –-N, -S and -H, -Ma, -Mn, -Mi, -Mpb, etc. n DB server type parameters : –-m1, -m2, -m3

6 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 6 New SQL92 Server Features Available With 9.1d n SQL92 server in 9.1d is multi-threaded n New parameters coming in 9.1d –Minimum clients per SQL92 server –Maximum clients per SQL92 server –Type of server a broker can start:-ServerType (Values are: 4GL, SQL or both)

7 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 7 Best Practices to Start SQL92 DB Servers n Goal: –Avoid networking resource issues linked to n -n n -minport and –maxport n Etc. n To achieve this goal: –Separate SQL servers from 4GL servers n Get an SQL only broker

8 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 8 Best Practices to Start SQL92 DB Servers n Hypotheses: –30 4GL connections: n 10 self service n 20 client-server –15 SQL connections n Warning: –In 9.1a, b and c, each SQL92 server can handle only one client at a time n To better manage network resources: start 2 brokers. One for SQL and one for 4GL clients

9 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 9 Best Practices to Start SQL92 DB Servers n Example of formula for 9.1a, b and c –Total number of clients: 45 with 19 servers + 1 secondary login broker –For the SQL broker: n Total number of SQL servers: 15 n Broker service number: 5000 n Server port range: [5100-5300] –For the 4GL broker: n Total number of 4GL servers: 4 n Max number of 4GL clients per server: 5 n Broker service number: 6000 n Server port range: [6100-6300]

10 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 10 Implementing the Example With Proserve n Example of commands for 9.1a, b and c –Start a 4GL broker (primary broker) n Proserve -S 6000 -H -n 45 -Mn 20 -Mpb 4 -Ma 5 -minport 6100 -maxport 6300 –Start an SQL broker as secondary broker n Proserve -S 5000 -H -m3 -Mpb 15 -Ma 1 -minport 5100 -maxport 5300 –To force a broker to spawn only a specific type of servers refer to KBase # 20570

11 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 11 Best Practices to Start SQL92 DB Servers n Example of formula for 9.1d –Total number of clients: 45 with 7 servers + 1 secondary login broker –For the SQL broker: n Total number of SQL servers: 3 n Max number of SQL clients per server: 5 n Broker service number: 5000 n Server port range: [5100-5300] –For the 4GL broker: n Total number of 4GL servers: 4 n Max number of 4GL clients per server: 5 n Broker service number: 6000 n Server port range: [6100-6300]

12 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 12 Implementing the Example With Proserve n Example of commands for 9.1d –Start a 4GL broker (Primary broker) n Proserve -S 6000 -H -n 45 -Mn 8 -Mpb 4 -ServerType 4GL -Ma 5 -minport 6100 -maxport 6300 –Start an SQL broker as secondary broker n Proserve -S 5000 -H -m3 -Mpb 3 -ServerType SQL -Ma 5 -minport 5100 -maxport 5300 n The primary Broker should always be the one with the highest value for -Ma

13 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 13 SQL Servers Client-server Configurations Recommended SQL client 4GL client 4GL only Broker SQL only Broker SQL client 4GL client Shared Memory Database 4GL Servers

14 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 14 SQL Server Architecture Comm. Manager SQL Statement Manager Statement Parser View Manager OptimizerAuthorization Manager Execution Manager Schema Manager Cost Manager Statistics Manager Transactional Relational Storage Manager Local Transaction Manager Network RPC Messages

15 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 15 Agenda n SQL92 servers administration n Database management –Database notions that differs from the 4GL –Schema management –Data definition language limits: ALTER TABLE –Data definition language: CREATE USER –Privileges management n SQL92 and transactions n SQL92 and performances n Some Successes

16 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 16 Database Notions That Differ From the 4GL n SQL important key words that differs from 4GL key words: –Catalog: 4GL schema –Schema: no equivalent notions –Columns: 4GL fields

17 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 17 Schema Management n A schema is an entity that helps define groups of tables with logical or functional links. Tables located in a schema usually share information pertaining to a specific set of operations n This means in the Progress implementation that –A schema is not linked to a user –A user has by default a schema attached to him which is named after the user ID (it is his own work space)

18 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 18 Schema Management n While developing / using an application, you may need to move from one schema to an other: –Use the SQL ‘set schema’ statement n Keep in mind that you can not create / alter / drop schema –They are implicit –Represent a logical way of grouping tables

19 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 19 Data Definition Language Limits: ALTER TABLE n Within a schema you have to perform database administration tasks: –In 9.1a,b,c,d you can only create and drop tables –In the next Progress version, phase 1 of ALTER TABLE is implemented: n Renaming table

20 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 20 Data Definition Language Limits: ALTER TABLE n Best practices to “mimic” ALTER TABLE for tables located in the ‘pub’ schema –Use the 4GL dictionary n Limits: –Can not define primary and candidate keys –Can not define foreign keys n Allows easy modification of the table definition

21 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 21 Data Definition Language Limits: ALTER TABLE n Best practices to “mimic” ALTER TABLE for tables not located in the ‘pub’ schema –CREATE TABLE sql92.State ( State CHAR(4) NOT NULL PRIMARY KEY, Region VARCHAR(4)) AS SELECT state, '' FROM pub.State; n Limits: –Difficult operation when foreign keys are defined on the altered table n Allows easy modification of the table definition

22 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 22 Data Definition Language: CREATE USER n IMPORTANT to remember: –A SQL database is a closed system n Always requires a user ID and password to establish a connection –A 4GL database is an open system n Does not specifically require a user ID and password to establish a connection

23 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 23 Data Definition Language: CREATE USER n The ‘user’ table is shared between the SQL and 4GL environment n SQL has no notions of ‘BLANK USER’ n This means –Creating a first user via SQL is equivalent to creating a user from the progress data administration –The user list maintained via SQL (alter / drop users) is updated for the 4GL as well

24 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 24 Data Definition Language: CREATE USER n When no users are created: –4GL will not display a login dialogue-box –SQL will ALWAYS require a user ID and password, but they can be anything n When users are created: –4GL will display a login dialogue-box but still allow blank connections (if not disabled) –SQL will ALWAYS require a VALID login

25 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 25 Best Practice for User Creation n Depends on your environment: –SQL only connections: n Create users to allow user id and password validation from the SQL interface n Manage SQL privileges accordingly –SQL and 4GL connections: n Create users if security is used from the 4GL as well n Do not create users if 4GL does not use security n Manage SQL privileges accordingly

26 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 26 When Do We Check Privileges? Comm. Manager SQL Statement Manager Statement Parser View Manager OptimizerAuthorization Manager Execution Manager Schema Manager Cost Manager Statistics Manager Transactional Relational Storage Manager Local Transaction Manager Network RPC Messages

27 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 27 Privileges Management n In SQL, privileges are: –Checked each time an SQL request is processed –Applicable to different database “objects” –Associated to users or groups of users –Designed to permit or prevent specific actions or group of actions on database “objects” n SQL92 privileges differ from 4GL privileges

28 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 28 Two Main Types of Privileges n On the whole database –Give / restrict system administration privileges (DBA) –Give / restrict general creation privileges on a database (resource) n On tables, views & procedures –Give / restrict specific operations like: n Alter an object definition (table, view…) n Delete, insert, select and update records n Execute stored procedures n Granting your own privileges n Define constraints to an existing table

29 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 29 Privileges Are n Granted to / Revoked from –Everybody (database “object” is made public) –A specific user n Stored in –Sysprogress.SYSDBAUTH –Sysprogress.SYSTABAUTH –Sysprogress.SYSCOLAUTH n The cause of error: “Access Denied (Authorization failed)(7512)”

30 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 30 The Syntax n Two key statements to manage SQL-92 privileges: –GRANT: n Example GRANT { RESOURCE, DBA } TO username [, username ],... ; –REVOKE: n Example: REVOKE { RESOURCE, DBA } FROM { username [, username ],... }; n For the exact syntax check your “SQL-92 guide and reference manual”

31 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 31 Best Practices in Privileges Management n A DBA is the only person to have full privileges on a database n The first DBA is the database creator: –Do not use ‘SYSPROGRESS’ as DBA –Check the sysprogress.sysdbauth table to find out WHO the DBA is (if you forgot its ID) n No users other then DBA and the creator have privileges on new tables, views… –Privileges to other users need to be granted n There is no need to create users to give them privileges

32 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 32 Best Practices in Privileges Management n Before assigning privileges ask yourself: –Should this user have DBA / resources privileges? –Is this object selectable by everybody? (GRANT SELECT ON table TO PUBLIC) –Is this object updateable by everybody? (GRANT UPDATE ON table TO PUBLIC) –Is this object insert able by everybody? (GRANT INSERT ON table TO PUBLIC) –Etc

33 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 33 Agenda n SQL92 servers administration n Database management n SQL92 and transactions n Processing phenomena in a transactional environment n SQL92 isolation levels n Progress implementation n Best practices n SQL92 and performances n Some Successes

34 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 34 SQL92 and Transactions n Transaction control is explicit in SQL n Commit work n Rollback work But n Record locking is implicit in SQL n Record locking behavior differs for each SQL transaction isolation level

35 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 35 Processing Phenomena in a Transactional Environment n Dirty read –Scenario: n User 1 executes: –INSERT INTO pub.State (state, state_name, region) values (‘AB', 'Abcdefghij’, ‘ABCD'); n User 2 executes: select * from pub.State –User 2 sees: state ‘AB’ n User 1 executes: rollback work n User 2 has seen data that did not really exist! –Occurs when one user is updating / inserting a record while an other user is reading it, but that work is not committed to the database

36 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 36 Processing Phenomena in a Transactional Environment n Non repeatable read – Scenario: n User 1 executes: select * from pub.State n User 2 executes: –Update pub.State set state_name = 'hello world' where state = ‘AK’; Commit work; n User 1 re-executes: select * from pub.State –User 1 has updated records in his result set ! –Occurs when one user is repeating a read operation on the same records but has updated values

37 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 37 Processing Phenomena in a Transactional Environment n Phantom –Scenario: n User 1 executes: select * from pub.State n User 2 executes: –INSERT INTO pub.State (state, state_name, region) values (‘AB', 'Abcdefghij’, ‘ABCD'); Commit work; n User 1 re-executes: select * from pub.State –User 1 has new records in his result set ! –Occurs when one user is repeating a read operation on the same records but has new records in his result set

38 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 38 SQL92 Isolation Levels n 4 levels that affect the session wide record locking behavior –Uncommitted read –Committed read –Repeatable read (default) –Serializable

39 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 39 SQL92 Isolation Levels Dirty Read Non Repeatable Read Phantom Read Uncommitted Read Allowed Committed Read Prevented Allowed Repeatable Read Prevented Allowed Serializable Prevented

40 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 40 SQL92 Isolation Levels n Uncommitted read –Allows all processing phenomena to occur –No record and schema locks –Equivalent to a 4GL read-only session n Committed read –Prevents dirty reads but allows all other phenomena –Shared record locks on select (locks are immediately released) –Exclusive otherwise

41 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 41 SQL92 Isolation Levels n Repeatable read –Allows phantoms but prevents all other phenomena –Shared record locks on select, exclusive otherwise (locks are held until transaction end) –Roughly equivalent to a 4GL session n Serializable –Prevents all phenomena –Shared table locks on select, shared intent exclusive table locks otherwise

42 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 42 Progress Implementation Isolation Level SelectUpdate Table Lock Record Lock Table Lock Record Lock Uncommitted Read None Operation Not Allowed Committed Read Intent Share Intent Exclusive Repeatable Read Intent Share Intent Exclusive Serializable ShareNone Share Intent Exclusive

43 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 43 Progress Implementation n SQL92 needs –A locking mechanism different from 4GL –Locks are set at different levels: n Catalog n Table(s) n Record(s) n 4GL uses –Locks mainly at record level (default) –SQL92 locking behavior when required (For instance when using the data dictionary)

44 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 44 SQL92 Isolation Levels n Higher isolation level means: –Better data consistency (more record locks) –Lower performances n Lower isolation level means: –Lower data consistency (less record locks) –Better performances

45 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 45 Best Practices in Choosing Transaction Isolation Levels n In a multi-user environment –Un-committed read should be used for reporting applications that do not rely on data accuracy (ex: statistical information at the end of a month) –Committed read or repeatable read should be used in most cases –Serializable should be used for transactional applications that do require maximum data consistency n In single user environment use only committed read

46 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 46 Agenda n SQL92 servers administration n Database management n SQL92 and transactions n SQL92 and performances –When does optimization take place? –Manual query optimization –Automated query optimization –Best practices to keep good performances n Some Successes

47 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 47 When Does Optimization Take Place? Comm. Manager SQL Statement Manager Statement Parser View Manager OptimizerAuthorization Manager Execution Manager Schema Manager Cost Manager Statistics Manager Transactional Relational Storage Manager Local Transaction Manager Network RPC Messages

48 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 48 Automated Query Optimization n Optimization goal is to: –Sort the table list, from minimum number of records to highest number of records to access n Based on the information provided in the query –Access table with the best index n Optimization is complex

49 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 49 Automated Query Optimization n To achieve these goals, the optimizer will mainly use statistics based on: –Table cardinality –Value distribution in columns n In 9.1d there are new statistics to help decide: –Which index to use

50 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 50 Automated Query Optimization n Statistics are maintained with the SQL statement ‘update statistics’ n In 9.1a, b and c: –It can be executed per table –Has to be executed when no other user updates the database n And 9.1d ?

51 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 51 Automated Query Optimization n Starting with 9.1d: –Update statistics can be executed to build: n All statistics: –The complete database –On a specific table n Specific statistics on a specific table: –For each indexed column –All columns in a table –All indexes defined on this table –Only table cardinality –Runs on-line regardless of other users updating the database

52 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 52 Some Numbers … n Results for a mix of 19 customer queries, Windows client, Solaris Server (always compared to 9.1A considered as the base line) ReleaseTotal Query Time Relative Performance 9.1A1.001.00 x 9.1B0.751.32 x 9.1C0.561.79 x 9.1D0.119.29 x

53 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 53 Best Practices to Keep Good Performances n Monitor on a regular basis –Table access to find if indexes are missing –Table heavily modified with lots of 'transactions‘ (create / update / delete records) n Maintain when required –Statistics for indexes on a table –Statistics for indexed columns in a table –Statistics for table cardinality

54 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 54 Best Practices to Keep Good Performances n When to execute ‘update statistics’ –In 9.1a, b or c (due to locking behavior) n When the database is not used or when there is low activity n Execute the update statistics table per table –In 9.1d n Anytime n Execute the update statistics: –Per table n For all indexes in that table n For all indexed column in that table

55 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 55 Agenda n SQL92 servers administration n Database management n SQL92 and transactions n SQL92 and performances n Some Successes –J2EE –JDBC –JSP

56 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 56 Some Successes n J2EE architecture already in use: –Server WebSphere – JRun - JBoss –Progress 9.1C and D on AIX n JDBC architecture already in use: –Plain java application with JDK 1.3.1 –Progress 9.1C and D on all supported OS n JSP and Java Servlets applications already in use: –Apache + Tomcat –Progress 9.1C and 9.1D

57 © 2002, Progress Software CorporationPUG September 2002, Oslo, Norway 57 Questions


Download ppt "Getting Started With Progress SQL-92 Sébastien Haefelé, SQL92 Product Advocate The Progress Company."

Similar presentations


Ads by Google