An Oracle White Paper
January 2012
Understanding Optimizer Statistics
Introduction (1)
What are Optimizer Statistics? (2)
Table and Column Statistics (2)
Additional column statistics (3)
Index Statistics (10)
Gathering Statistics (11)
GATHER_TABLE_STATS (11)
Changing the default value for the parameters in
DBMS_STATS.GATHER_*_STATS (13)
Automatic Statistics Gathering Job (15)
Improving the efficiency of Gathering Statistics (18)
Concurrent Statistic gathering (18)
Gathering Statistics on Partitioned tables (20)
Managing statistics (22)
Restoring Statistics (22)
Pending Statistics (23)
Exporting / Importing Statistics (23)
Copying Partition Statistics (25)
Comparing Statistics (26)
Locking Statistics (27)
Manually setting Statistics (29)
Other Types of Statistics (29)
Dynamic Sampling (29)
System statistics (31)
Statistics on Dictionary Tables (32)
Statistics on Fixed Objects (32)
Conclusion (33)
Introduction
When the Oracle database was first introduced the decision of how to execute a SQL statement was determined by a Rule Based Optimizer (RBO). The Rule Based Optimizer, as the name implies, followed a set of rules to determine the execution plan for a SQL statement. The rules were ranked so if there were two possible rules that could be applied to a SQL statement the rule with the lowest rank would be used.
In Oracle Database 7, the Cost Based Optimizer (CBO) was introduced to deal with the enhanced functionality being added to the Oracle Database at this time, including parallel execution and partitioning, and to take the actual data content and distribution into account. The Cost Based Optimizer examines all of the possible plans for a SQL statement and picks the one with the lowest cost, where cost represents the estimated resource usage for a given plan. The lower the cost the more efficient an execution plan is expected to be. In order for the Cost Based Optimizer to accurately determine the cost for an execution plan it must have information about all of the objects (tables and indexes) accessed in the SQL statement, and information about the system on which the SQL statement will be run.
This necessary information is commonly referred to as Optimizer statistics. Understanding and managing Optimizer statistics is key to optimal SQL execution. Knowing when and how to gather statistics in a timely manner is critical to maintaining acceptable performance. This whitepaper is the first in a two part series on Optimizer statistics, and describes in detail, with worked examples, the different concepts of Optimizer statistics including;
?What are Optimizer statistics
?Gathering statistics
?Managing statistics
?Additional types of statistics
What are Optimizer Statistics?
Optimizer statistics are a collection of data that describe the database, and the objects in the database. These statistics are used by the Optimizer to choose the best execution plan for each SQL statement. Statistics are stored in the data dictionary, and can be accessed using data dictionary views such as USER_TAB_STATISTICS. Optimizer statistics are different from the performance statistics visible through V$ views. The information in the V$ views relates to the state of the system and the SQL workload executing on it.
Figure 1. Optimizer Statistics stored in the data dictionary used by the Optimizer to determine execution plans
Table and Column Statistics
Table statistics include information on the number of rows in the table, the number of data blocks used for the table, as well as the average row length in the table. The Optimizer uses this information, in conjunction with other statistics, to compute the cost of various operations in an execution plan, and to estimate the number of rows the operation will produce. For example, the cost of a table access is calculated using the number of data blocks combined with the value of the parameter
DB_FILE_MULTIBLOCK_READ_COUNT. You can view table statistics in the dictionary view
USER_TAB_STATISTICS.
Column statistics include information on the number of distinct values in a column (NDV) as well as the minimum and maximum value found in the column. You can view column statistics in the dictionary view USER_TAB_COL_STATISTICS. The Optimizer uses the column statistics information in conjunction with the table statistics (number of rows) to estimate the number of rows that will be
returned by a SQL operation. For example, if a table has 100 records, and the table access evaluates an equality predicate on a column that has 10 distinct values, then the Optimizer, assuming uniform data distribution, estimates the cardinality to be the number of rows in the table divided by the number of distinct values for the column or 100/10 = 10.
Figure 2. Cardinality calculation using basic table and column statistics
Additional column statistics
Basic table and column statistics tell the optimizer a great deal but they don’t provide a mechanism to tell the Optimizer about the nature of the data in the table or column. For example, these statistics can’t tell the Optimizer if there is a data skew in a column, or if there is a correlation between columns in a table. Information on the nature of the data can be provided to the Optimizer by using extensions to basic statistics like, histograms, column groups, and expression statistics.
Histograms
Histograms tell the Optimizer about the distribution of data within a column. By default (without a histogram), the Optimizer assumes a uniform distribution of rows across the distinct values in a column. As described above, the Optimizer calculates the cardinality for an equality predicate by dividing the total number of rows in the table by the number of distinct values in the column used in the equality predicate. If the data distribution in that column is not uniform (i.e., a data skew) then the cardinality estimate will be incorrect. In order to accurately reflect a non-uniform data distribution, a histogram is required on the column. The presence of a histogram changes the formula used by the Optimizer to estimate the cardinality, and allows it to generate a more accurate execution plan. Oracle automatically determines the columns that need histograms based on the column usage information (SYS.COL_USAGE$), and the presence of a data skew. For example, Oracle will not automatically create a histogram on a unique column if it is only seen in equality predicates.
There are two types of histograms, frequency or height-balanced. Oracle determines the type of histogram to be created based on the number of distinct values in the column.
Frequency Histograms
Frequency histograms are created when the number of distinct values in the column is less than 254. Oracle uses the following steps to create a frequency histogram.
1.Let’s assume that Oracle is creating a frequency histogram on the PROMO_CATEGORY_ID
column of the PROMOTIONS table. The first step is to select the PROMO_CATEGORY_ID from
the PROMOTIONS table ordered by PROMO_CATEGORY_ID.
2.Each PROMO_CATEGORY_ID is then assigned to its own histogram bucket (Figure 3).
Figure 3. Step 2 in frequency histogram creation
3.At this stage we could have more than 254 histogram buckets, so the buckets that hold the
same value are then compressed into the highest bucket with that value. In this case, buckets 2 through 115 are compressed into bucket 115, and buckets 484 through 503 are compressed
into bucket 503, and so on until the total number of buckets remaining equals the number of
distinct values in the column (Figure 4). Note the above steps are for illustration purposes.
The DBMS_STATS package has been optimized to build compressed histograms directly.
Figure 4. Step 3 in frequency histogram creation: duplicate buckets are compressed
4.The Optimizer now accurately determines the cardinality for predicates on the
PROMO_CATEGORY_ID column using the frequency histogram. For example, for the predicate PROMO_CATEGORY_ID=10, the Optimizer would first need to determine how many buckets in the histogram have 10 as their end point. It does this by finding the bucket whose endpoint is 10, bucket 503, and then subtracts the previous bucket number, bucket 483, 503 - 483 = 20.
Then the cardinality estimate would be calculated using the following formula (number of
bucket endpoints / total number of bucket) X NUM_ROWS, 20/503 X 503, so the number
of rows in the PROMOTOINS table where PROMO_CATEGORY_ID=10 is 20.
Height balanced Histograms
Height-balanced histograms are created when the number of distinct values in the column is greater than 254. In a height-balanced histogram, column values are divided into buckets so that each bucket contains approximately the same number of rows. Oracle uses the following steps to create a height-balanced histogram.
1.Let’s assume that Oracle is crea ting a height-balanced histogram on the CUST_CITY_ID
column of the CUSTOMERS table because the number of distinct values in the CUST_CITY_ID column is greater than 254. Just like with a frequency histogram, the first step is to
select the CUST_CITY_ID from the CUSTOMERS table ordered by CUST_CITY_ID.
2.There are 55,500 rows in the CUSTOMERS table and there is a maximum of 254 buckets in a
histogram. In order to have an equal number of rows in each bucket, Oracle must put 219
rows in each bucket. The 219th CUST_CITY_ID from step one will become the endpoint for
the first bucket. In this case that is 51043. The 438th CUST_CITY_ID from step one will
become the endpoint for the second bucket, and so on until all 254 buckets are filled (Figure
5).
Figure 5. Step 2 of height-balance histogram creation: put an equal number of rows in each bucket
3.Once the buckets have been created Oracle checks to see if the endpoint of the first bucket is
the minimum value for the CUST_CITY_ID column. If it is not, a “zero” bucket is added to the histogram that has the minimum value for the CUST_CITY_ID column as its end point (Figure 6).
Figure 6. Step 3 of height-balance histogram creation: add a zero bucket for the min value
4.Just as with a frequency histogram, the final step is to compress the height-balanced
histogram, and remove the buckets with duplicate end points. The value 51166 is the end
point for bucket 24 and bucket 25 in our height-balanced histogram on the CUST_CITY_ID column. So, bucket 24 will be compressed in bucket 25 (Figure 7).
Figure 7. Step 4 of height-balance histogram creation
5.The Optimizer now computes a better cardinality estimate for predicates on the
CUST_CITY_ID column by using the height-balanced histogram. For example, for the
predicate CUST_CITY_ID =51806, the Optimizer would first check to see how many buckets in the histogram have 51806 as their end point. In this case, the endpoint for bucket
136,137,138 and 139 is 51806(info found in USER_HISTOGRAMS). The Optimizer then uses the following formula:
(Number of bucket endpoints / total number of buckets) X number of rows in the table
In this case 4/254 X 55500 = 874
Figure 8. Height balanced histogram used for popular value cardinality estimate
However, if the predicate was CUST_CITY_ID =52500, which is not the endpoint for any bucket then the Optimizer uses a different formula. For values that are the endpoint for only one bucket or are not an endpoint at all, the Optimizer uses the following formula: DENSITY X number of rows in the table
where DENSITY is calculated ‘on the fly’ during optimization using an internal formula based
on information in the histogram. The value for DENSITY seen in the dictionary view
USER_TAB_COL_STATISTICS is not the value used by the Optimizer from Oracle Database
10.2.0.4 onwards. This value is recorded for backward compatibility, as this is the value used
in Oracle Database 9i and earlier releases of 10g. Furthermore, if the parameter
OPTIMIZER_FEATURES_ENABLE is set to version release earlier than 10.2.0.4, the value for
DENSITY in the dictionary view will be used.
Figure 9. Height balanced histogram used for non- popular value cardinality estimate
Extended Statistics
In Oracle Database 11g, extensions to column statistics were introduced. Extended statistics encompasses two additional types of statistics; column groups and expression statistics.
Column Groups
In real-world data, there is often a relationship (correlation) between the data stored in different columns of the same table. For example, in the CUSTOMERS table, the values in the
CUST_STATE_PROVINCE column are influenced by the values in the COUNTRY_ID column, as the state of California is only going to be found in the United States. Using only basic column statistics, the Optimizer has no way of knowing about these real-world relationships, and could potentially miscalculate the cardinality if multiple columns from the same table are used in the where clause of a statement. The Optimizer can be made aware of these real-world relationships by having extended statistics on these columns as a group.
By creating statistics on a group of columns, the Optimizer can compute a better cardinality estimate when several the columns from the same table are used together in a where clause of a SQL statement. You can use the function DBMS_STATS.CREATE_EXTENDED_STATS to define a column group you want to have statistics gathered on as a group. Once a column group has been created, Oracle will automatically maintain the statistics on that column group when statistics are gathered on the table, just like it does for any ordinary column (Figure 10).
Figure 10. Creating a column group on the CUSTOMERS table
After creating the column group and re-gathering statistics, you will see an additional column, with a system-generated name, in the dictionary view USER_TAB_COL_STATISTICS. This new column represents the column group (Figure 11).
Figure 11. System generated column name for a column group in USER_TAB_COL_STATISTICS
To map the system-generated column name to the column group and to see what other extended statistics exist for a user schema, you can query the dictionary view USER_STAT_EXTENSIONS (Figure 12).
Figure 12. Information about column groups is stored in USER_STAT_EXTENSIONS
The Optimizer will now use the column group statistics, rather than the individual column statistics when these columns are used together in where clause predicates. Not all of the columns in the column
group need to be present in the SQL statement for the Optimizer to use extended statistics; only a subset of the columns is necessary.
Expression Statistics
It is also possible to create extended statistics for an expression (including functions), to help the Optimizer to estimate the cardinality of a where clause predicate that has columns embedded inside expressions. For example, if it is common to have a where clause predicate that uses the UPPER function on a cus tomer’s last name, UPPER(CUST_LAST_NAME)=:B1, then it would be beneficial to create extended statistics for the expression UPPER(CUST_LAST_NAME)(Figure 13).
Figure 13. Extended statistics can also be created on expressions
Just as with column groups, statistics need to be re-gathered on the table after the expression statistics have been defined. After the statistics have been gathered, an additional column with a system-generated name will appear in the dictionary view USER_TAB_COL_STATISTICS representing the expression statistics. Just like for column groups, the detailed information about expression statistics can be found in USER_STAT_EXTENSIONS.
Restrictions on Extended Statistics
Extended statistics can only be used when the where the clause predicates are equalities or in-lists. Extended statistics will not be used if there are histograms present on the underlying columns and there is no histogram present on the column group.
Index Statistics
Index statistics provide information on the number of distinct values in the index (distinct keys), the depth of the index (blevel), the number of leaf blocks in the index (leaf_blocks), and the clustering factor1. The Optimizer uses this information in conjunction with other statistics to determine the cost of an index access. For example the Optimizer will use b-level, leaf_blocks and the table statistics num_rows to determine the cost of an index range scan (when all predicates are on the leading edge of the index).
1Chapter 11 of the Oracle? Database Performance Tuning Guide
Gathering Statistics
For database objects that are constantly changing, statistics must be regularly gathered so that they accurately describe the database object. The PL/SQL package, DBMS_STATS, i s Oracle’s preferred method for gathering statistics, and replaces the now obsolete ANALYZE2 command for collecting statistics. The DBMS_STATS package contains over 50 different procedures for gathering and managing statistics but most important of these procedures are the GATHER_*_STATS procedures. These procedures can be used to gather table, column, and index statistics. You will need to be the owner of the object or have the ANALYZE ANY system privilege or the DBA role to run these procedures. The parameters used by these procedures are nearly identical, so this paper will focus on the
GATHER_TABLE_STATS procedure.
GATHER_TABLE_STATS
The DBMS_STATS.GATHER_TABLE_STATS procedure allows you to gather table, partition, index, and column statistics. Although it takes 15 different parameters, only the first two or three parameters need to be specified to run the procedure, and are sufficient for most customers;
?The name of the schema containing the table
?The name of the table
? A specific partition name if it’s a partitioned table and you only want to collect statistics for a specific partition (optional)
Figure 14. Using the DBMS_STATS.GATHER_TABLE_STATS procedure
The remaining parameters can be left at their default values in most cases. Out of the remaining 12 parameters, the following are often changed from their default and warrant some explanation here. ESTIMATE_PERCENT parameter
The ESTIMATE_PERCENT parameter determines the percentage of rows used to calculate the statistics. The most accurate statistics are gathered when all rows in the table are processed (i.e., 100% sample), often referred to as computed statistics. Oracle Database 11g introduced a new sampling algorithm that is hash based and provides deterministic statistics. This new approach has the accuracy close to a 2 ANALYZE command is still used to VALIDATE or LIST CHAINED ROWS.
100% sample but with the cost of, at most, a 10% sample. The new algorithm is used when ESTIMATE_PERCENT is set to AUTO_SAMPLE_SIZE (the default) in any of the
DBMS_STATS.GATHER_*_STATS procedures. Historically, customers have set the
ESTIMATE_PRECENT parameter to a low value to ensure that the statistics will be gathered quickly. However, without detailed testing, it is difficult to know which sample size to use to get accurate statistics. It is highly recommended that from Oracle Database 11g onward you let
ESTIMATE_PRECENT default (i.e., not set explicitly).
METHOD_OPT parameter
The METHOD_OPT parameter controls the creation of histograms during statistics collection. Histograms are a special type of column statistic created when the data in a table column has a non-uniform distribution, as discussed in the previous section of this paper. With the default value of FOR ALL COLUMNS SIZE AUTO, Oracle automatically determines which columns require histograms and the number of buckets that will be used based on the column usage information
(DBMS_STATS.REPORT_COL_USAGE) and the number of distinct values in the column. The column usage information reflects an analysis of all the SQL operations the database has processed for a given object. Column usage tracking is enabled by default.
A column is a candidate for a histogram if it has been seen in a where clause predicate, e.g., an equality, range, LIKE, etc. Oracle also verifies if the column data is skewed before creating a histogram, for example a unique column will not have a histogram created on it if it is only seen in equality predicates. It is strongly recommended you let the METHOD_OPT parameter default in the GATHER_*_STATS procedures.
DEGREE parameter
The DEGREE parameter controls the number of parallel server processes that will be used to gather the statistics. By default Oracle uses the same number of parallel server processes specified as an attribute of the table in the data dictionary (Degree of Parallelism). By default, all tables in an Oracle database have this attribute set to 1, so it may be useful to set this parameter if statistics are being gathered on a large table to speed up statistics collection. By setting the parameter DEGREE to AUTO_DEGREE, Oracle will automatically determine the appropriate number of parallel server processes that should be used to gather statistics, based on the size of an object. The value can be between 1 (serial execution) for small objects to DEFAULT_DEGREE (PARALLEL_THREADS_PER_CPU X CPU_COUNT) for larger objects. GRANULARITY parameter
The GRANULARITY parameter dictates the levels at which statistics are gathered on a partitioned table. The possible levels are table (global), partition, or sub-partition. By default Oracle will determine which levels are necessary based on the table’s partitioning strategy. Statistics are always gathered on the first level of partitioning regardless of the partitioning type used. Sub-partition statistics are gathered when the subpartitioning type is LIST or RANGE. This parameter is ignored if the table is not partitioned.
CASCADE parameter
The CASCADE parameter determines whether or not statistics are gathered for the indexes on a table. By default, AUTO_CASCADE, Oracle will only re-gather statistics for indexes whose table statistics are stale. Cascade is often set to false when a large direct path data load is done and the indexes are disabled. After the load has been completed, the indexes are rebuilt and statistics will be automatically created for them, negating the need to gather index statistics when the table statistics are gathered.
NO_INVALIDATE parameter
The NO_INVALIDATE parameter determines if dependent cursors (cursors that access the table whose statistics are being re-gathered) will be invalidated immediately after statistics are gathered or not. With the default setting of DBMS_STATS.AUTO_INVALIDATE, cursors (statements that have already been parsed) will not be invalidated immediately. They will continue to use the plan built using the previous statistics until Oracle decides to invalidate the dependent cursors based on internal heuristics. The invalidations will happen gradually over time to ensure there is no performance impact on the shared pool or spike in CPU usage as there could be if you have a large number of dependent cursors and all of them were hard parsed at once.
Changing the default value for the parameters in DBMS_STATS.GATHER_*_STATS You can specify a particular non-default parameter value for an individual
DBMS_STATS.GATHER_*_STATS command, or override the default value for your database. You can override the default parameter values for DBMS_STATS.GATHER_*_STATS procedures using the DBMS_STATS.SET_*_PREFS procedures. The list of parameters that can be changed are as follows: AUTOSTATS_TARGET (SET_GLOBAL_PREFS only as it relates to the auto stats job) CONCURRENT (SET_GLOBAL_PREFS only)
CASCADE
DEGREE
ESTIMATE_PERCENT
METHOD_OPT
NO_INVALIDATE
GRANULARITY
PUBLISH
INCREMENTAL
STALE_PERCENT
You can override the default settings for each parameter at a table, schema, database, or global level using one of the following DBMS_STATS.SET_*_PREFS procedures, with the exception of AUTOSTATS_TARGET and CONCURRENT which can only be modified at the global level.
SET_TABLE_PREFS
SET_SCHEMA_PREFS
SET_DATABASE_PREFS
SET_GLOBAL_PREFS
The SET_TABLE_PREFS procedure allows you to change the default values of the parameters used by the DBMS_STATS.GATHER_*_STATS procedures for the specified table only.
The SET_SCHEMA_PREFS procedure allows you to change the default values of the parameters used by the DBMS_STATS.GATHER_*_STATS procedures for all of the existing tables in the specified schema. This procedure actually calls the SET_TABLE_PREFS procedure for each of the tables in the specified schema. Since it uses SET_TABLE_PREFS, calling this procedure will not affect any new objects created after it has been run. New objects will pick up the GLOBAL preference values for all parameters.
The SET_DATABASE_PREFS procedure allows you to change the default values of the parameters used by the DBMS_STATS.GATHER_*_STATS procedures for all of the user-defined schemas in the database. This procedure actually calls the SET_TABLE_PREFS procedure for each table in each user-defined schema. Since it uses SET_TABLE_PREFS this procedure will not affect any new objects created after it has been run. New objects will pick up the GLOBAL preference values for all parameters. It is also possible to include the Oracle owned schemas (sys, system, etc) by setting the ADD_SYS parameter to TRUE.
The SET_GLOBAL_PREFS procedure allows you to change the default values of the parameters used by the DBMS_STATS.GATHER_*_STATS procedures for any object in the database that does not have an existing table preference. All parameters default to the global setting unless there is a table preference set, or the parameter is explicitly set in the GATHER_*_STATS command. Changes made by this procedure will affect any new objects created after it has been run. New objects will pick up the GLOBAL_PREFS values for all parameters.
With SET_GLOBAL_PREFS it is also possible to set a default value for two additional parameters, AUTOSTAT_TARGET and CONCURRENT. AUTOSTAT_TARGET controls what objects the automatic statistic gathering job (that runs in the nightly maintenance window) will look after. The possible values for this parameter are ALL, ORACLE, and AUTO. The default value is AUTO. A more in-depth discussion about the automatic statistics collection can be found in the statistics management section of this paper.
The CONCURRENT parameter controls whether or not statistics will be gathered on multiple tables in a schema (or database), and multiple (sub)partitions within a table concurrently. It is a Boolean parameter, and is set to FALSE by default. The value of the CONCURRENT parameter does not impact the automatic statistics gathering job, which always does one object at a time. A more in-depth discussion about concurrent statistics gathering can be found in the Improving the efficiency of Gathering Statistics section of this paper.
The DBMS_STATS.GATHER_*_STATS procedures and the automatic statistics gathering job obeys the following hierarchy for parameter values; parameter values explicitly set in the command overrule everything else. If the parameter has not been set in the command, we check for a table level preference. If there is no table preference set, we use the GLOBAL preference.
Figure 15. DBMS_STATS.GATHER_*_STATS hierarchy for parameter values
If you are unsure of what preferences have been set, you can use the DBMS_STATS.GET_PREFS function to check. The function takes three arguments; the name of the parameter, the schema name, and the table name. In the example below (figure 16), we first check the value of STALE_PRECENT on the SH.SALES table. Then we set a table level preference, and check that it took affect using
DBMS_STATS.GET_PREFS.
Figure 16. Using DBMS_STATS.SET_PREFS procedure to change the parameter stale_percent for the sales table Automatic Statistics Gathering Job
Oracle will automatically collect statistics for all database objects, which are missing statistics or have stale statistics by running an Oracle AutoTask task during a predefined maintenance window (10pm to 2am weekdays and 6am to 2am at the weekends).
This AutoTask gathers Optimizer statistics by calling the internal procedure
DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC. This procedure operates in a very similar
fashion to the DBMS_STATS.GATHER_DATABASE_STATS procedure using the GATHER AUTO option. The primary difference is that Oracle internally prioritizes the database objects that require statistics, so that those objects, which most need updated statistics, are processed first. You can verify that the automatic statistics gathering job exists by querying the DBA_AUTOTASK_CLIENT_JOB view or through Enterprise Manager (Figure 17). You can also change the maintenance window that the job will run in through Enterprise Manager.
Figure 17. Checking that the automatic statistics gathering job is enabled
Statistics on a table are considered stale when more than STALE_PERCENT (default 10%) of the rows are changed (total number of inserts, deletes, updates) in the table. Oracle monitors the DML activity for all tables and records it in the SGA. The monitoring information is periodically flushed to disk, and is exposed in the *_TAB_MODIFICATIONS view.
Figure 18. Querying USER_TAB_MODIFICATIONS view to check DML activity on the PRODUCTS2 table
It is possible to manually flush this data by calling the procedure
DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO if you want to get up-to-date information at query time (internally the monitoring data is flushed before all statistics collection operations). You can then see which tables have stale statistics by querying the STALE_STATS column in the
USER_TAB_STATISTICS view.
Figure 19. Querying USER_TAB_STATISTICS to see if any tables have stale statistics
Tables where STALE_STATS is set to NO, have up to date statistics. Tables where STALE_STATS is set to YES, have stale statistics. Tables where STALE_STATS is not set are missing statistics altogether.
If you already have a well-established statistics gathering procedure or if for some other reason you want to disable automatic statistics gathering for your main application schema, consider leaving it on for the dictionary tables. You can do this by changing the value of AUTOSTATS_TARGET to ORACLE instead of AUTO using DBMS_STATS.SET_GLOBAL_PREFS procedure.
BEGIN
DBMS_STATS.SET_GLOBAL_PREFS(‘AUTOSTATS_TARGET’,’ORACLE’);
END;
/
To disable the task altogether:
BEGIN
DBMS_AUTO_TASK_ADMIN.DISABLE(
client_name => 'auto optimizer stats collection',
operation => NULL,
window_name => NULL);
END;
/
Improving the efficiency of Gathering Statistics
Once you define the statistics you are interested in, you want to ensure to collect these statistics in a timely manner. Traditionally people have sped up statistics gathering by using parallel execution as discussed above. However, what if all of the objects a schema were small and didn’t warrant parallel execution, how could you speed up gathering statistics on that schema?
Concurrent Statistic gathering
In Oracle Database 11g Release 2 (11.2.0.2), a concurrent statistics gathering mode was introduced to gather statistics on multiple tables in a schema (or database), and multiple (sub)partitions within a table concurrently. Gathering statistics on multiple tables and (sub)partitions concurrently can reduce the overall time it takes to gather statistics by allowing Oracle to fully utilize a multi-processor environment.
Concurrent statistics gathering is controlled by the global preference, CONCURRENT, which is set to either TRUE or FALSE. By default it is set to FALSE. When CONCURRENT is set to TRUE, Oracle employs Oracle Job Scheduler and Advanced Queuing components to create and manage multiple statistics gathering jobs concurrently.
Calling DBMS_STATS.GATHER_TABLE_STATS on a partitioned table when CONCURRENT is set to TRUE, causes Oracle to create a separate statistics gathering job for each (sub)partition in the table. How many of these jobs will execute concurrently, and how many will be queued is based on the number of available job queue processes (JOB_QUEUE_PROCESSES initialization parameter, per node on a RAC environment) and the available system resources. As the currently running jobs complete, more jobs will be dequeued and executed until all of the (sub)partitions have had their statistics gathered.
If you gather statistics using DBMS_STATS.GATHER_DATABASE_STATS,
DBMS_STATS.GATHER_SCHEMA_STATS, or DBMS_STATS.GATHER_DICTIONARY_STATS, then Oracle will create a separate statistics gathering job for each non-partitioned table, and each (sub)partition for the partitioned tables. Each partitioned table will also have a coordinator job that manages its (sub)partition jobs. The database will then run as many concurrent jobs as possible, and queue the remaining jobs until the executing jobs complete. However, to prevent possible deadlock scenarios multiple partitioned tables cannot be processed simultaneously. Hence, if there are some jobs running for a partitioned table, other partitioned tables in a schema (or database or dictionary) will be queued until the current one completes. There is no such restriction for non-partitioned tables.
The following figure illustrates the creation of jobs at different levels, when a
DBMS_STATS.GATHER_SCHEMA_STATS command has been issued on the SH schema. Oracle will create a statistics gathering job (Level 1 in Figure 20) for each of the non-partitioned tables; CHANNELS,
COUNTRIES,
CUSTOMERS,
PRODUCTS,
PROMOTIONS,
TIMES
甲骨文中国乱象:渠道混乱售后屡遭投诉 来源：赛迪网-《中国计算机报》2009年12月14日作者：窦彦莉编辑：赖正河2009-12-16 星期三杭州网 “请你设想这样的情况：从现在起5年之后，10年之后，或30年之后，今天站在你左边的这个人会是一个失败者；右边的这个人，同样，也是个失败者。而你，站在中间的家伙，你以为你会怎样？一样是失败者——失败的经历，失败的优等生。” 2000年，甲骨文董事长兼CEO拉里·埃里森在耶鲁大学发表演讲时，面对台下1000名即将毕业的大学生曾说出这样的惊人言论。然而，两年后的6月中旬，在首次于中国举行的甲骨文全球电子商务和新技术大会上（Oracle World），一向心高气傲、口无遮拦、走到哪里都不忘挖苦对手的拉里·埃里森，面对实施甲骨文ERP项目失败的中国用户的当场质问，却没能做出正面回应。 秘而不宣的银行客户名单 “这只是冰山一角，其实，Oracle ERP的银行项目在中国实施到今天，都没有拿到一份用户的成功验收报告！” 前段时间，在谈及某重要IT门户网站报道的某农村商业银行“520万元甲骨文ERP项目失败之谜”时，一位业内人士不经意的一句话，立即引起了记者的关注。 打开甲骨文中国的官方网站，我们发现甲骨文的金融客户中只有重庆市商业银行、广东发展银行、宁波银行股份有限公司、深圳发展银行、厦门市商业银行5家银行客户。 “其实远不止这些，据我所知，中国银行、宁夏银行、南京银行、山东省农村信用社联合社、泉州市商业银行、徽商银行、国开行、民生银行、渤海银行、广东农村信用社等都是甲骨文的客户。” 曾参与过某银行甲骨文ERP项目实施，并有着十几年ERP项目实施经验的G先生说。 既然有这么多银行客户，那为什么在甲骨文中国的官方网站没有显示呢？在当前几乎所有ERP厂商都大肆宣传自己的成功案例的情况下，甲骨文中国的做法似乎令人费解。 记者随即对此展开了调查。 ERP项目失败如何界定 据了解，国外研究机构对ERP的应用效果进行了大量研究，并且针对ERP实施的成功与否给出了严格的界定。欧美研究机构的专家认为，ERP实施成功可以从两个方面定义：第
从甲骨文、金文、楷体龙字看古“龙”之变 摘要：“”、“”、“”、“龙”等甲骨文、金文、楷体龙字含有的图腾信息，揭示出中国古龙在原始的蛇型龙之后，经历的从火蛇型龙到阴阳双构型龙，由从阴阳双构型龙再到兼具“日月之明”的独体龙的形义演变过程。后三种类型之龙皆为具有相对广泛认同基础的共祖性质之龙。三种形态祖龙不同程度的阴阳属性，是将其与其它形式的龙区分开来的标志。 关键词：古龙字；图腾；龙变 龙是中国文化中的一个谜一样的神物。著名学者闻一多认为，龙是以蛇为主干和基调，由不同图腾糅合而成的虚拟生物。部落联盟的图腾为“混合”图腾，部落融合后的图腾为“化合”图腾。在图腾未合并以前，龙只是一种大蛇；蛇与龙从来纠缠不清，也不必将蛇与龙分清[1]19～21。但其又认为混合图腾中的各子图腾，在部落“融化”（部落）过程完成之后，各自的原始意蕴最终消失，彼此融合、质变为“一个新的大单位”[1]20。然而，只要承认龙是以蛇为基调，由不同图腾组合、演化而来，龙都应是一个“化合”之物，它必然和蛇有着本质的区别。 甲骨文、金文中的古龙字，是由特定氏族的图腾符号构成的○1。我们今天所能见到的古龙字，大体包括商代甲骨文“”、“”，周代金文“”及汉代楷体“龙”四种形态 [2]612。这些龙字中图腾符号的混合、“化合”意蕴，反映了龙是一个从类型到性质都有所演变的文化现象，蛇与龙是既有区别又有共性、区别大于共性的不同之“物”。 一、伏羲氏原始形态的蛇型之龙 传说伏羲“有龙瑞，以龙纪官，号曰龙师”[3]《三皇本纪》，龙似是伏羲氏族的专有
图腾。如果龙是伏羲氏族的专有图腾，那么龙字也和龙图腾一样，应是伏羲氏族的专有符号。传说伏羲氏“蛇身人首” [4]卷一《自开辟至三皇》，甲骨文“”字就似一蛇形之龙。甲骨文“”形龙字[2]612，就更具蛇形之象。金文中又有一图画性较强的龚字[2]152，如图1，其中“”部的蛇形表征更为明显。闻一多认为这一形态的龙的本质，即为一条大蛇不无道理。这应当是存留至商代的一个龙的认知观念。 许多部落经历过非部落联盟的发展阶段，这一阶段的氏族图腾应是独体形态的图腾，即闻一多所言的未与其它图腾合并以前的图腾。“”字的 字形相对原始，当象原始的伏羲氏族的图腾之形。图腾是氏族的标志， 氏族图腾与氏族互为表里。那么，“”的本义是指伏羲氏的图腾， 并代表伏羲氏族之义。伏羲人首蛇身的形象，也是建立在这种图腾形 象之上的。或者说，伏羲的形象，就是蛇形龙图腾的人格化。商代甲骨文“”形龙字，应是原始的伏羲文化在商代的历史延续。 然而，除伏羲氏族之外，远古传说中的北山诸神、轩辕国之人、钟山之神及相柳等也都是“人首蛇身”的形象[5]95、226、277、280。如果这些同伏羲氏图腾一样的“人首蛇身”之蛇也为蛇形之龙，那么远古以蛇形之龙为图腾的部落是普遍存在的。此氏族的蛇形之龙并不为其彼氏族所认同，因而史料记载有蛇形之龙被他族所食的现象。如延维为二首之蛇，“人主得而飨食之，伯天下”[5]518。就此而论，这一发展阶段的伏羲氏的“”形龙图腾，尚未获得广泛的氏族认同并拥有共祖图腾的地位。 这一时期的蛇型之龙的普遍存在，表明当时的伏羲氏仅是各部落中的一个普通部落，其文明的发展程度和其它氏族部落相差不大。那么，商代甲骨文“”形龙字，可能并非仅是伏羲氏的图腾符号。但以相似的蛇型之龙为图腾的众多部族，可能为后世以伏羲氏为主力的蛇龙氏族的融合奠定了基础。诸多伏羲氏族与其它图腾类型氏族关系的发展，以其与燧人氏部落联盟的建立为转折点，原始的蛇形之龙出现混合发展的趋势。 二、伏羲氏蛇型之龙与燧人图腾的混合
如果说钻木取火标志着人类告别了茹毛饮血的野蛮岁月，那么文字的出现就意味着人类走出了结绳记事的洪荒年代。甲骨文的发现，正是照亮中华文明的一盏明灯。甲骨文不仅仅是一个文明的符号、文化的标志，它还印证了包括《史记》在内的一系列文献的真实，把有记载的中华文明史向前推进了近5个世纪。在世界四大古文字体系中，唯有以殷墟甲骨文为 代表的中国古汉字体系，历经数千年的演变而承续至今，书写出了一部博大精深的中华文明史。目前，安阳殷墟共出土甲骨15万片，单字约4500个，其中约有1500个单字已被释读。3000多年以来，甲骨文虽然经过了金文、篆书、隶书、楷书等不同书写形式的变化，但是以形、音、义为特征的文字和基本语法保留至今，成为今天世界上五分之一人口仍在使用的方块字，对中国人的思维方式、审美观产生了重要的影响，为中国书法艺术的产生与发展奠定了基础。 所以，对于甲骨文的出土以及对其的相关研究，我们可以归结出甲骨文的四点意义： 1、是证实了中国早期国家——商王国的存在。在殷墟甲骨文发现以前，人们只能从有限的文献记载中知道历史上有个商王朝，而且这些文献无一是成于商代的。而殷墟甲骨文的发现，将大量的商人亲手书写、契刻的文字展现在学者面前，使商史与传说时代分离而进入历史时代。特别是1917年王国维写了《殷卜辞中所见先公先王考》及《续考》，证明《史记·殷本纪》与《世本》所载殷王世系几乎皆可由卜辞资料印证，是基本可靠的。同时，他根据缀合的两片卜辞，发现上甲以后几位先公之次序应是报乙、报丙、报丁，《史记》以报丁、报乙、报丙为序，是后世传抄而成的。这篇著名的论文，无可辩驳地证明《殷本纪》所载商王朝是确实存在的。这不仅是中国历史研究的一件大事，而且鉴于殷商文明在世界文明史上的重要地位，这一发现也是世界历史研究中一件值得大书特书的事。 2、在于王国维用甲骨文证实了《殷本纪》的史料价值，使《史记》之类历史文献有关中国古史记载的可信性增强，其意义不仅局限于商史。因为这一发现促使史学家们想到，既然《殷本纪》中的商王世系基本可信，司马迁的《史记》也确如刘向、扬雄所言是一部“实录”，那么司马迁在《夏本纪》中所记录的夏王朝与夏王世系也恐非是向壁虚构。特别是在20年代疑古思潮流行时期，甲骨文资料证实了《殷本纪》与《世本》的可靠程度，也使历史学家开始摆脱困惑，对古典文献的可靠性恢复了信心。 3、是引发了震撼中外学术界的殷墟发掘。“五四”运动促使中国的历史学界发生两大变化，一是提倡实事求是的科学态度，古史辨派对一切经不住史证的旧史学的无情批判，“使人痛 感到中国古史上科学的考古资料的极端贫乏”。二是历史唯物主义在史学界产生巨大影响。1925年王国维在清华国学研究院讲授《古史新证》，力倡“二重证据法”，亦使中国历史学 研究者开始重视地下出土的新材料。这些历史因素对近代考古学在中国的兴起起了催生作用。1927年秋，前中央研究院历史语言研究所开始发掘殷墟，其最初的目的就是为了继续在此地寻找甲骨。当李济主持第二次发掘时，已开始从主要寻找甲骨变成对整个遗址所有遗存的科学发掘，认识到“凡是经过人工的、埋在地下的资料，不管它是否有文字，都可以作研究 人类历史的资料”。并从而取得以后14次发掘的重大收获，所以可以说，正是甲骨文的发现揭开了中国现代考古学的序幕。
甲骨文书法与董作宾书法鉴赏 甲骨文书法有广义、狭义之分。广义而言，包括“以刀代笔”的契刻卜辞的书法艺术，和“以笔代刀”的卜文（甲骨文）笔墨书法艺术。狭义而言，指后者“以笔代刀”的卜文笔墨书法。现在通常讲的甲骨文书法，主要指的是“以笔代刀”的卜文笔墨书法。 殷商甲骨文具有应用和艺术的双重性。殷商甲骨文虽说是三千多年前殷商时期刻写在龟骨，兽骨上记载占卜，祭祀等活动的古文字，但却是成熟的形体兼备的文字，可称上是书法。因为殷商的人们己有了将汉字书写得整齐美观的观念,且在点画、结字、布局方面已基本上确立了后世汉字书写及书法艺术的格局。甲骨文字的点划基本上是均齐划一的等线性，首尾则多取尖势。这固然与以刀刻骨这种具体“书写”方式有关，但风格在这里的趋向统一，也完全可以证明．人们在这种整齐划一之中铭刻下对整齐美、技巧美的执着追求的。以刀刻骨的难以驾驭与一丝不苟的谙练娴熟之间的强烈对比，更促使这种美的价值迅速增长。点画虽均齐而偏细，但却有质感、有力度，又显示着人们在笔画质地美方面的审美意识的觉醒。 郭沫若先生在《殷英粹编》中提出第一四六八片，刻十个干支字，“刻而又刻者数行，中仅一行盖精美整齐，余则歪刺几不能成字。然此歪刺者中，却间有二三字,与精美整齐者之一行相同。盖精美整齐者乃善书旁刻者之范本，而歪刺不能成字者乃学书学刻之摩伎也。刻鹄不成，为师范者从容捉刀助之，故间有二三字合乎规矩、师弟二人蔼然相对之态。情如目前。” 此外当时有了‘专业’的书写者。用甲骨进行占卜，有一套严密的程序和分工。在《周礼? 春官》中记载有掌管卜事的“大卜”，“卜师”、“龟人”、“垂氏”等官名。在甲骨文实物中，不仅发现了卜辞中有“贞人”的名字。而且在甲骨的甲桥、甲尾、背甲和牛骨的骨臼、骨面上发现了“入者”、“示者”、“乞者”等的签名。在这样细致的分工中应当包括专门的契刻者，也就是甲骨文的专门书写者。我们还在商铭文中，发现了肥瘦相间的笔道、这说明当时已经使用毛笔并有了提按运笔的意识．并且最为重要地发现甲骨文出现了不同的书写风格，书法中的雄浑，精细、奇恣等美学范畴已经初露端倪。如《祭祀狩猎涂朱牛骨刻辞》，商代武丁时期的作品，风格豪放，字形大小错落，生动有致，各尽其态，富有变化而又自然潇洒。这标志着汉字书写已经上升为艺术。 殷商甲骨文奠定了中国书法艺术的基本形式，是书法艺术迈出的第一步。因为殷商甲骨文已具备了中国书法的三个基本要素：用笔，结字，章法。因此我们谈到甲骨文书法史有必要从殷商开始。 殷商甲骨文书法 公元前一千三百年，商朝的第二十代君王盘庚把都城从亳迁到殷，经过一系列的复古改制，中兴了即将崩溃的商王朝。嗣后，小辛、小乙、武丁、祖庚、祖甲、廪辛、康丁、武乙、文丁、帝乙、帝辛（即殷纣王），八代十二王皆建都于此。殷作为后期商朝的都城，前后历时共二百七十三年。而在这二百七十三年里，却给后人留下了王室占卜时的记录——甲骨文。 我们从《大戴礼记?表记》中知道“殷人尊神，率民以事神，先鬼而后礼。”也就是说，在殷王朝时，是十分迷信的，他们在日常生活中，敬事鬼神，崇尚占卜，凡事必卜，每卜又多至数次。《论衡?卜筮篇》：“钻龟揲蓍有吉凶之兆者，逢吉遭凶之类也。何以明之？周武王不豫，周公卜之龟。公曰，乃逢是吉。”由出土的卜辞得知，商代常“一事多卜，不限之龟，”其内容也十分复杂的，凡祭祀，征战，田猎，疾病，风雨晦暝，年成欠丰，出入的吉凶，旬夕的安否，用人用性之多寡，妇人生育之男女，无不求之占卜以请命于上天。就是在这种原始思维的导向下巫术活动中的文字才被渐渐地丰富和发展起来了。故今人称这些占卜的文字为“卜
汉字的演变历史（甲骨文-金文-大篆- 小篆-隶书-楷体） 甲骨文：又称“契文”、“甲骨卜辞”或“龟甲兽骨文”，主要指中国商朝晚期（前14～前11世纪）王室用于占卜记事而在龟甲或兽骨上契刻的文字，殷商灭亡周朝兴起之后，甲骨文还延绵使用了一段时期。是中国已知最早的成体系的文字形式，它上承原始刻绘符号，下启青铜铭文，是汉字发展的关键形态。现代汉字即由甲骨文演变而来。 它的特点是： 象形性强，有很强的描画物象的色彩，甲骨文笔画消瘦，直笔与转折多，且书写置向不定，字形结构不固定，异形字多，字体往往是以所表示实物的繁简决定大小，有的一个字可以占上几个字的位置，也可有长、有短。在字的构造方面，有些象形字只注重突出实物的特征，而笔画多少、正反向背却不统一。甲骨文的一些会意字，只要求偏旁会合起来含义明确，而不要求固定。因此甲骨文中的异体字非常多，有的一个字可有十几个甚至几十个写法。因为字是用刀刻在较硬的兽骨上，所以笔画较细，方笔居多。由于甲骨文是用刀刻成的，而刀有锐有钝，骨质有细有粗，有硬有软，所以刻出的笔画粗细不一，甚至有的纤细如发，笔画的连接处又有剥落，浑厚粗重。结构上，长短大小均无一定，或是疏
疏落落，参差错综；或是密密层层十分严整庄重，故能显出古朴多姿的无限情趣。 甲骨文，结体上虽然大小不一，错综变化，但已具有对称、稳定的格局。所以有人认为，中国的书法，严格讲是由甲骨文开始，因为甲骨文已备书法的三个要素，即用笔、结字、章法。 金文，是指铸刻在殷周青铜器上的铭文，也叫钟鼎文。商周是青铜器的时代，青铜器的礼器以鼎为代表，乐器以钟为代表，“钟鼎”是青铜器的代名词。因为周以前把铜也叫金，所以铜器上的铭文就叫作“金文”或“吉金文字”；又因为这类铜器以钟鼎上的字数最多，所以过去又叫作“钟鼎文”。金文应用的年代，上自商代的早期，下至秦灭六国，约1200多年。金文的字数，据容庚《金文编》记载，共计3722个，其中可以识别的字有2420个。与甲骨文相比，甲骨文笔道细、直笔多、转折处多，为方形有所不同，金文笔道肥粗，弯笔多，团块多。且整体遒丽，古朴厚重，异体字繁多，象形性强，金文与甲骨文结构无大的区别，字体只是有明显区别而已。 大篆；大篆又有籀文、籀篆、籀书、史书之称。周宣王时，太史籀作《大篆》十五篇，因其为籀所作，故世称“籀文”。“籀文”乃据古文而作，是在古文基础上整理出来的，故其与古文或同或异。由金文发展而来。
第十一章 甲骨学与殷商史研究要籍 一、甲骨文字考释的专书 1.《契文举例》孙诒让，撰于1904年，但直到1913年此书原稿才在上海被王国维发现，后方得到出版。是甲骨学史上第一部研究著作。该书所据材料，仅《铁云藏龟》一书。1917年《吉金盦丛书》本一册，1927年上海蟫隐庐石印本二册。 《契文举例》共分十章。即： 月日第一贞卜第二卜事第三 鬼神第四卜人第五官事第六 方国第七典礼第八文字第九 杂例第十 这是将甲骨文按内容进行分类的最早尝试。《契文举例》一书所考释的文字，在今天看来，基本已无可取，但从历史的发展观点来看，此书“在甲骨学史上筚路蓝缕，它的草创之功是不能抹煞的”。 2.《殷墟书契考释》罗振玉，1914年石印本一册，1927年东方学会石印增订本三卷三册。他在文字考证的基础上，结合史籍，再考求商代典制，“所得则有六端”：“一曰帝系”，“二曰京邑”，“三曰祀礼”，“四曰卜法”，“五曰官制”，“六曰文字”。共考释并加以解说四八五字。至1927年有将其增订出版，《增订殷墟书契考释》增至五七一字。罗振玉《殷墟书契考释》及《增订殷墟书契考释》在甲骨学史上占有重要地位。 3.《殷卜辞中所见先公先王考》、《续考》及《戬寿堂所藏殷墟文字考释》《先公先王考》及《续考》，王国维1917年发表，收入《学术丛书》及《观堂集林》卷九。此二文不仅考证了甲骨文中所见殷代先公先王，而且是“把甲骨文学研究推向一个新阶段，标志着‘文字时期’进入了‘史料时期’”的重要论文。 4.《甲骨文字研究》郭沫若，1931年大东书局石印本二册，1982年科学出版社合《甲骨文字研究》、《殷契余论》、《安阳新出土的牛胛骨及其刻辞》等为一编，以《甲骨文字研究》为书名，作为《郭沫若全集》考古编第一卷出版。郭沫若此书，不仅对断片缀合、残辞互补、缺刻横划、分期断代等方面多有发现，而且在文字考释方面也颇有创获。此书开辟了用历史唯物主义研究甲骨文字的新途径，在甲骨学史上占有重要地位。 5.《双剑誃殷契骈枝三编》于省吾，初编1940年石印本一册，续编1941年石印本一册，三编1944年石印本一册。全书共收考释文章98篇，文字考释简练、精到、严谨，并将所释就之字再放到有关卜辞中去核校，做到了文从字顺，在学术界有重大影响。 6.《甲骨文字释林》于省吾，1979年中华书局出版。本书上卷是将《双剑誃殷契骈枝三编》所收98篇论文加以删订，共存53篇而成。本书的中、下卷，一部分是经过删削的作者解放前所写《骈枝》四编中的文章，有十篇是重新改写的。另一部分是改写、改定的解放后在报刊上发表的一系列文字考释论文。全书共收入文字考释之作190篇。《甲骨文字释林》一书是于省吾研究甲骨文的总结，考证并加以解说了300个甲骨文字，为甲骨学的研究作出了重大贡献。 7.《积微居甲文说卜辞琐记》杨树达，中国科学院1954年出版。该书卷上说字的论文共三三篇，分识字、说义、说通读、说形等四类。卷下考史论文共二〇篇，分人名、国名、水名、祭祀、杂考等五项。《卜辞琐记》之部则收入考证四九条。书中所考文字及史事皆较允当，而且文字精练，至今仍有参考价值。 8.《耐林庼甲文说卜辞求义》杨树达，1954年群联出版社印行。本书《耐林庼甲文说》之部
甲骨文书法欣赏 甲骨文书法欣赏一、引言 在人类发展史上，文字的创造和应用是人类从荒蛮走向文明的象征，而在世界上以古埃及的圣书字、古代两河流域的楔形文字和中国的古文字为主的各国古文字中，汉字则是唯一的从产生到现在延续使用数千年还依然充满生命活力的一棵长青树。而以汉字书写作为表现形式的书法艺术，是世界所公认的最为纯粹的中华艺术，是中国传统文化的重要组成部分。书法发展成为一门独立的艺术，是在草、行、隶、楷等今文字字体先后成熟的魏晋时代，先秦古文字退出了社会实用字体的舞台，仅在特殊场合使用。尽管此后也有对它们艺术特色的高度赞扬，依然有书法家喜欢运用古文字作为书法的表现形式，但从书学理论到艺术实践，都明显存在着厚今文字字体而薄古文字书法的倾向。虽然由于文字演变和古今审美意趣变化，这种倾向的产生自属“势在必然”，但是古文字书法和今文字书法所能体现的审美范畴，所能造就的艺术意境是完全不同的，更是不能相互替代的。同样，古文字书法中不同字体的书法也是这样。因此，如果缺少了历史上任何一种成熟字体（如古文字中的甲骨文、金文、楚简、帛书等）书法，这个系统就是不完美的，中国书法这座“东方艺术的最高峰”就不那么雄伟壮丽了。为了全面继承和弘扬传统
书法，我们应该在重视今文字书法的同时，加大对整个古文字书法从理论到实践进行研究与探索的力度。 殷墟甲骨文是三千多年前我国最早有系统的成熟的文字，不仅表现于字的个数之多，也表现在字的结构复杂，古人所说的“六书”：象形、会意、形声、指事、转注、假借，在甲骨文中都可找到实例。清光绪二十五年（1899年）甲骨文被著名学者王懿荣发现至今的百余年中，有许多前辈学者在甲骨学的建立和发展中，起到了奠基和开拓的关键性作用，其中最为人们称道的是甲骨学史上的“四堂”：即参照《说文解字》并利用金文字形与卜辞相互验证，考释出大量甲骨文且纠正了不少《说文解字》的谬误，在甲骨的搜集、著录、考释等方面都做出突出贡献的雪堂（罗振玉）；将卜辞系联为有系统的古史材料，用以重构商史并推测其社会制度，使《史记·殷本记》和《帝王世纪》等书所传的殷代王说得到物证的新史学开拓者观堂（王国维）；将盘庚迁殷至商纣灭亡8世12王的二百多年历史划分五个时期，具有划时代意义的著名“王朝断代说”创造者彦堂（董作宾）；以研究古文字手段来研究中国古代社会，并在商世系的考证和甲骨文字的考释等方面，有许多独特创见的鼎堂（郭沫若）。 甲骨文的发现，是中国近代文化史上的一件大事，它不仅给史学界、考古学界、文字学界提出了一系列崭新的研究课题，也对中国书法有着巨大的影响。它那千姿百态的构形，高古
庄浪县实验小学学校基本情况统计表 表一:学校规模、教师队伍、校园情况表 创办时 间 学校等级及评定时间学校法人白钱珠 学校规 模年级一二三四五六其他总计班数 6 4 3 4 5 6 33 人数46 45 46 45 224 274 1550 班均 人数 46 45 46 45 45 46 47 教师队 伍总人数学历校长卫生技 术人员 职称 心理健康 教师证书 等级110 本科以 上 本科以上学历 比例（％） 专科 专科以上学历 比例（％） 中师 （高中） 达标人数达标率（％）学历职称 33 30 77 70 110 100 本科小高 c 校园总占地面积（㎡）生均占地面积（㎡）总建筑面积（㎡） 其中 生均建筑面积（不含 宿舍）（㎡） 教学和行政学生宿舍36125 23.3 12865 8800 4065 4.75
表二：教学、行政、生活用房情况表 编号名称间数使用面积 （㎡） 编号名称间数 使用面积 （㎡） 编号名称间数 使用面积 （㎡） 1 普通教室33 207 2 16 地理园（中学填） 1 210 31 教师阅览室 1 56 2 科学探究实验室（小学填） 1 56 17 生物园（中学填） 1 1930 32 学生阅览室 1 56 3 科学仪器准备室（小学填） 1 28 18 计算机室 2 112 33 展览室或校史室 1 28 4 物理实验室（中学填） 1 56 19 语音室 2 56 34 会议室 2 188 5 物理仪器室（中学填） 1 5 6 20 音乐室 1 56 35 礼堂 6 化学实验室（中学填） 1 56 21 舞蹈室 1 112 36 食堂 1 330 7 化学仪器室（中学填） 1 56 22 乐器室37 党政办公室 1 28 8 生物实验室室（中学填） 1 56 23 美术室 1 56 38 教师办公室 5 280 9 生物标本实验室 1 28 24 体育馆或室内体育室39 教务室 2 56 10 多媒体综合电教室11 672 25 体育器材室 1 28 40 政教室 1 28 11 软件制作室 1 28 26 卫生室 1 28 41 总务室 2 56 12 电教主控室27 心理辅导室 1 28 42 团（队）室 2 56 13 综合档案室 1 56 28 科技活动室 1 28 43 广播室 2 56 14 历史室（中学填） 1 28 29 劳技室（综合实践活动 室） 1 28 44 文印室 1 28 15 地理室（中学填） 1 28 30 藏书室 1 56 其它
汉字的演变过程 古代汉字的演变大致分为：从甲骨文→金文→大篆→小篆→隶书→草书→楷书→行书的过程， 1. 甲骨文：汉字是世界上最古老的文字之一，最古老而又完备的汉字是殷墟甲骨文，距今有三千多年。而汉字产生的年代应该比甲骨文早得多。 甲骨文是商周时代刻在龟甲兽骨上的文字。已发现甲骨文单字有4500字左右，可认识的约1700字。这些是现存的甲骨文与现代简化字的对比图片。 2. 金文：金文叫钟鼎文，盛行于西周，是铸刻在青铜器上的文字。金文的形体和结构与甲骨文相似，金文的笔画特点是：字形圆转，大小均匀。象形性比甲骨文有所降低，字的定型性有所提高。 3. 大篆：大篆是西周晚期的一种文字，形体与金文大体一致，具有笔画繁多的特点。在原有文字的基础上进行了改革，因刻于石鼓上而得名，是流传至今最早的刻石文字。 4. 小篆：小篆是秦代的统一字体，经过整理、简化，所以异体字大量减少，且字形呈长方，奠定了汉字“方块形”的基础。因为小篆在大篆的基础上简化而成，一般说小篆是大篆的简体。 5. 隶书：隶书产生于秦代，盛行于汉代。为了便于书写，隶书将小篆圆转均匀的线条变成了方折平直、粗细有致的笔画；隶书对汉字字体的改变是巨大的，因此，“隶变”就成了古今汉字的分界。 6. 草书：草书是秦隶的草化、连笔而成。始于汉初，当时通用的是“草隶”，即潦草的隶书，后来逐渐发展，形成一种具有艺术价值的“章草”。汉末，张芝变革“章草”为“今草”，字的体势一笔而成。唐代张旭、怀素又发展为笔势连绵回绕，字形变化繁多，称为“狂草”。 7. 楷书：楷书产生于汉末，盛行于魏、晋、南北朝时期，成熟于唐代，一直沿用至今。它完全清除了隶书中残存的小篆的影响，形成了完善的笔画系统。 8. 行书：行书是楷书的快写体，介于草、楷之间，可以说是楷书的草化。它是为了弥补楷书的书写速度太慢和草书的难于辨认而产生的。 综上所述：汉字经过六千多年的变化，发展成七种不同的结体方式。“甲金篆隶草楷行”称为“汉字七体”。我们可以看到：汉字字形的总体发展趋势是由繁到简，汉字在不断趋于定型化、规范化。 由于发展的需要，繁体字简化为简体字。简体字一般是指中国现代中文的法定标准写法。繁体字的简化，减少了汉字的笔画数和汉字的数目，因而降低了汉字学习的难度，同时加快了书写速度，有利于普及教育。
1977 年拉里·艾利森(Larry Ellison)、Bob Miner 和Ed Oates 共同创建了软件开发实验室(Software Development Laboratories)。1970 年IBM 的一名研究人员写了一篇名为《大型共享数据库的关系数据模型》的研究论文，他们三人受到这篇文章的启发，决定构建一种新型数据库，称为关系数据库系统(relational database system) 。 他们所接手的第一个项目是为美国政府做的，他们将之命名为Oracle。他们认为Oracle 意思是“智慧之源”，用来作为这个项目的名称十分恰当，也会得到CIA 的认可。 1978 年软件开发实验室从原来的圣克拉克迁至位于硅谷心脏的Menlo Park 的Sand Hill 大街上。 为了让人们了解公司的主要业务范围，他们将软件开发实验室更名为关系软件公司(Relationa Software Inc. (RSI))。 1979 年RSI 开发出第一款商用SQL 数据库— V2(V1 根本就未推出过)。 1982 年RSI 更名为Oracle 系统公司(Oracle System Corporation)，Oracle 公司。用产品名称为公司命名，帮助公司赢得了业界的认同。 1983 年Oracle 决定开发便携式RDBMS。Oracle 开发出V3，这是第一款在PC 机、小型机及大型机上运行的便携式数据库。 1984 年年收入达到1,270 万美元 Oracle 迁至贝尔蒙特市戴维斯20 号一栋84,000 平方英尺的办公楼内。
推出Portable Toolset。 这一年设立了: Oracle 加拿大公司 Oracle 荷兰公司 Oracle 英国有限公司 1985 年年收入达到2,300 万美元 这一年设立了: Oracle 奥地利公司 Oracle 德国公司 Oracle 日本公司 Oracle 瑞典公司 Oracle 瑞士公司 1986 年年收入达到5,500 万美元 1986 年3 月12 日推出IPO（首次公开募股）。当日公司股票以15 美元开盘，20.75 美元收盘。推出第一个客户端/服务器数据库。 这一年设立了: Oracle 澳大利亚公司 Oracle 芬兰公司 Oracle 法国公司 Oracle 系统香港有限公司 Oracle 挪威公司 Oracle 西班牙公司
甲骨文概述甲骨文概述 2013-12-27 甲骨文书法有广义、狭义之分。广义而言，包括“以刀代笔”的契刻卜辞的书法艺术，和“以笔代刀”的卜文（甲骨文）笔墨书法艺术。狭义而言，指后者“以笔代刀”的卜文笔墨书法。现在通常讲的甲骨文书法，主要指的是“以笔代刀”的卜文笔墨书法。 殷商甲骨文具有应用和艺术的双重性。殷商甲骨文虽说是三千多年前殷商时期刻写在龟骨，兽骨上记载占卜，祭祀等活动的古文字，但却是成熟的形体兼备的文字，可称上是书法。因为殷商的人们己有了将汉字书写得整齐美观的观念,且在点画、结字、布局方面已基本上确立了后世汉字书写及书法艺术的格局。甲骨文字的点划基本上是均齐划一的等线性，首尾则多取尖势。这固然与以刀刻骨这种具体“书写”方式有关，但风格在这里的趋向统一，也完全可以证明．人们在这种整齐划一之中铭刻下对整齐美、技巧美的执着追求的。以刀刻骨的难以驾驭与一丝不苟的谙练娴熟之间的强烈对比，更促使这种美的价值迅速增长。点画虽均齐而偏细，但却有质感、有力度，又显示着人们在笔画质地美方面的审美意识的觉醒。 郭沫若先生在《殷英粹编》中提出第一四六八片，刻十个干支字，“刻而又刻者数行，中仅一行盖精美整齐，余则歪刺几不能成字。然此歪刺者中，却间有二三字,与精美整齐者之一行相同。盖精美整齐者乃善书旁刻者之范本，而歪刺不能成字者乃学书学刻之
摩伎也。刻鹄不成，为师范者从容捉刀助之，故间有二三字合乎规矩、师弟二人蔼然相对之态。情如目前。” 此外当时有了‘专业’的书写者。用甲骨进行占卜，有一套严密的程序和分工。在《周礼 ? 春官》中记载有掌管卜事的“大卜”，“卜师”、“龟人”、“垂氏”等官名。在甲骨文实物中，不仅发现了卜辞中有“贞人”的名字。而且在甲骨的甲桥、甲尾、背甲和牛骨的骨臼、骨面上发现了“入者”、“示者”、“乞者”等的签名。在这样细致的分工中应当包括专门的契刻者，也就是甲骨文的专门书写者。我们还在商铭文中，发现了肥瘦相间的笔道、这说明当时已经使用毛笔并有了提按运笔的意识．并且最为重要地发现甲骨文出现了不同的书写风格，书法中的雄浑，精细、奇恣等美学范畴已经初露端倪。如《祭祀狩猎涂朱牛骨刻辞》，商代武丁时期的作品，风格豪放，字形大小错落，生动有致，各尽其态，富有变化而又自然潇洒。这标志着汉字书写已经上升为艺术。 殷商甲骨文奠定了中国书法艺术的基本形式，是书法艺术迈出的第一步。因为殷商甲骨文已具备了中国书法的三个基本要素：用笔，结字，章法。因此我们谈到甲骨文书法史有必要从殷商开始。 殷商甲骨文书法 公元前一千三百年，商朝的第二十代君王盘庚把都城从亳迁到殷，经过一系列的复古改制，中兴了即将崩溃的商王朝。嗣后，小辛、小乙、武丁、祖庚、祖甲、廪辛、康丁、武乙、文丁、帝乙、帝辛（即殷纣王），八代十二王皆建都于此。殷作为后期商朝的都
甲骨文 古汉字一种书体的名称。刻在甲、骨上的文字早先曾称为契文，甲骨刻辞、卜辞、龟版文、殷墟文字等，现通称甲骨文。殷代（商朝）人用龟甲、兽骨（主要是牛肩胛骨）占卜。在占卜后把占卜日期、占卜者的名字、所占卜的事情用刀刻在卜兆的旁边，有的还把过若干日后的吉凶应验也刻上去,最详细的一条将近100字。学者称这种记录为卜辞，这种文字为甲骨文。是中国商代后期（前14～前11世纪）王室用于占卜记事而刻（或写）在龟甲和兽骨上的文字。它是中国已发现的古代文字中时代最早、体系较为完整的文字。甲骨文发现于河南省安阳县小屯村一带，是商王般庚迁殷以后到纣王亡国时的遗物（公元前14世纪中期～前11世纪中期），距今已3000多年。 商朝人好占卜，以火灼烧甲骨出现的“兆”（细小的纵横裂纹）预测未来的吉凶。甲包括龟的腹甲与背甲，骨多为或牛的肩胛骨与肋骨。甲骨文初发现于河南省安阳县小屯村一带，距今约三千馀年，经过鉴定是比篆文、籀文更早的文字。
刻在肩胛骨上的甲骨文 清光绪二十四年（1898年）以前，当地的农民在采收花生时，偶然捡到一些龟甲和兽骨，被当成中药卖给药铺，清末金石学家王懿荣和学生赵军偶然在中药材上的“龙骨”片发现有古文字，经过查证后才知道是商代国都所在地。但后人考证王懿荣并非发现甲骨文的第一人，其他尚有王襄、孟定生、刘鹗、端方、胡石查等人。最初，在古物中获利的人为垄断甲骨文，故意把出土地点说成是汤阴或卫辉，学者多受其误导。 1928年中央研究院历史语言研究所由董作宾领导，第一次有计划对甲骨文的考古发掘，共有六人参加，至1937年，前后共进行十五次；发掘地点，除了洹水南岸的小屯村以外，更扩大到后冈、和洹水北岸的侯家庄西北冈、高井台子、大司空村等地。一共出土龟甲、兽骨有二万四千九百多片。抗战期间，工作被迫停止，有大量的甲骨随同众多文物等被运往日本，达一万二千多片。 1973年小屯南地出土4805片甲骨文。 1991年殷墟花园庄东地H3坑中出土甲骨文689片。 甲骨文 甲骨文的内容大部分是殷商王室占卜的纪录。商朝的人皆迷信鬼神，大事小事都要卜问，有些占卜的内容是天气晴雨，有些是农作收成，也有问病痛、求子的，而打猎、作战、祭祀等大事，更是需要卜问了！所以甲骨文的内容可以隐略了解商朝人的生活情形，也可以得知商朝历史发展的状况。
全部《甲骨文对照表》，书法练字必备！ 书法教程：田英章楷书书法《异体字》集锦打开打开书法知识：书体简介之一，甲骨文。打开第一届世界超逼真绘画大赛|正在悄然进行打开书法教程：田英章楷书书法《异体字》集锦打开打开全部《甲骨文对照表》，书法练字必备！书法之家1天前17评论关注路过的朋友，点击关注我们哦~本文共收录一千多个甲骨文与现代简体字的相互对照。甲骨文没有计算机字库，以下对照表以图片形式呈现： 《全部甲骨文对照表》 ﹀觉得好就下面点个赞吧！展开阅读全文热门推荐不会书法？只要练好这八个字，可以露一手打开APP无真文化大观222条评论书法练字有窍门，这样写字绝对神打开APP大家书法105条评论博士妈妈真有才，把英语单词编成三字经，孩子1天记住500个单词！打开APP印子老师62条评论练好32个大字，以备挥毫不时之需打开APP书法之美323条评论鬼才数学老师：小学数学无非就这6张图，背熟考试次次不下98分！打开APP惊喜199818条评论记住行书的这些要诀，练就一首漂亮难得的好字并不难打开APP清雅阁书画63条评论猜你喜欢《中国成语300句》——卢中南楷书欣赏（下）打开APP艺术家视界12条评论英语单词编成三字经，孩子1天记住500词！我家孩子就是这么记的！打开
APP课海家长22条评论回归传统，从摹入临,让书法学习少走弯路打开APP闻是书画11条评论电表转得飞快？教你1招，一个月能省一半电费！聪明人都爱用！打开APP七爷车扯淡188条评论拼音口诀儿歌，背过它，孩子拼音不用愁打开APP喔喔爱原创57条评论解密欧阳询楷书，最难写的五个部首，不信你试试打开APP王羲之搞笑书法22条评论最容易读错的240个汉字，看完后看看你认对了几个？打开APP艺道中国100条评论这些常考常错的字，都在这里了，不要再错下去了！打开APP追梦小多多59条评论《九成宫》最难的五个笔法，对于初学者而言，第五个最要命！打开APP王羲之搞笑书法46条评论硬笔书法规律与口诀，一看就懂打开APP书法初学49条评论为什么掌握好书法技巧，毛笔字就能写得炉火纯青、行云流水?打开APP松风阁书法日讲4条评论楷书结体的四个“核心”，文虽短，有启发打开APP书法密码5条评论写好这60个字，楷书成了一半！打开APP不二斋111条评论这样写楷书，永远写不好！打开APP沃德利成书画院0条评论五行起名大全，命理中缺什么，名字中就要补什么打开APP宝宝取名好帮手3条评论男孩分床睡不能超过这个年龄，不然影响孩子一生，你家孩子分了吗打开APP木棉之城318条评论毛笔字入门的关键技巧，一旦突破就能越写越顺打开APP放心购精选3条评论学书法，一定要认识这些异体字！打开APP笔墨中国16条评论书法
一、汉字的演变过程表： 汉字经过了6000多年的变化，其演变过程是： 甲骨文→金文→小篆→隶书→楷书→行书(商)(周)(秦)(汉)(魏晋)草书 以上的“甲金篆隶草楷行”七种字体称为“汉字七体”。 ●汉字的产生,有据可查的,是在约公元前14世纪的殷商后期,这时形成了初步的定型文字, 即甲骨文.甲骨文既是象形字又是表音字,至今汉字中仍有一些和图画一样的象形文字,十分生动. ●到了西周后期,汉字发展演变为大篆.后来秦朝丞相李斯对大篆加以去繁就简,改为小篆.●至汉代,隶书发展到了成熟的阶段,汉字的易读性和书写速度都大大提高. ●隶书之后又演变为章草,而后今草,至唐朝有了抒发书者胸臆,寄情于笔端表现的狂草. ●随后,糅和了隶书和草书而自成一体的楷书（又称真书）在唐朝开始盛行.我们今天所用 的印刷体,即由楷书变化而来. ●介于楷书与草书之间的是行书,它书写流畅,用笔灵活,据传是汉代刘德升所制,传至今日, 仍是我们日常书写所习惯使用的字体. 二、五个阶段 汉字的演变过程，可以简略归纳为五个阶段：声、形、象、数、理。 ⑴“声”是任何一种语言的必要组成部分。在遥远漫长的太古时代，人类从本能的“哭声、笑声……”或模仿大自然的“鸟鸣、虫叫、兽吼、风声、雷声、雨声……”中逐渐分化出具有一定意义、代表一定事物的“声音”，“鹅、鸡、鸭、猫……”等家禽和家畜可能是依据其叫声而定其名的。 ⑵“形”是语言的第二个重要组成部分，但不是必要的。在远古时代人类主要面临的是生存和种族延续问题。在与大自然和猛兽毒蛇等的斗争过程中，有时需要用“形”或“画”来表示事物。例如：远出狩猎，为了不至于迷失道路，可能在岩石上或树干上做一些标记。人类在狩猎时，也注意观察野兽的足迹，以辨别出野兽的特性。另外，人类也可能出于对神秘大自然的崇拜或对美的事物的追求，在岩洞壁上，画上“日、月、人、山、木、屮、动物、祖先……”等图象。 ⑶“象”是创造汉字和《易》说理预事的主要方法。“日、月”等属于象形文字，是造字的基本部件。 ⑷“数”概念是人类长期进化过程中逐渐形成的。 ⑸“理”是“象、数”的扩展。汉字外延的演变主要是通过“理”来扩大的，即相“象”的事物，“理”也相通。例如：“明”本意是明亮，延伸出“眼睛看得清楚、心里明白、事情
- 1 - 古文字學之二大「顯學」 －－「甲骨學」及「金文學」系列 楊志團 本校中正圖書館典藏有關古文字學之圖書相當豐富。其中，有關甲骨學、金文學之圖書尤為完備，欲研究此二門學科者，不可不知。本文擬就館藏有關甲骨文、金文研究較為重要書籍，作簡要介紹，以供讀者參考。 清末甲骨文之發現，以及「古文字學」是研究古今漢字演變規律的專門學科。其作用不僅僅在於釋讀文字，還可據以釋讀文獻，進而了解古代文化。研究古器物文字始於漢代，許慎《說文解字．敘》云：「郡國亦往往於山川得鼎彝，其銘即前代之古文。」許慎所言之古文，即青銅器銘文，而青銅器銘文為古文字學其中一類。許多簡牘、帛書等器物大 量出土，豐富了古文字學研究內容，使得古文字學研究不再侷限於傳統金石學，進而擴大範圍。古文字學之類別以書寫器物區分，可分為甲骨文、金文、簡帛文字、石器文字、印璽文字、貨幣文字、陶文、漆書等類，各個類別又可成為一專門獨立學科，如「甲骨學」、「金文學」。其中，甲骨學、金文學在古文字學研究中歷史較為悠久，研究成果也頗
- 2 - 為可觀，可以稱的上是古文字學研究中的兩門「顯學」。 甲骨學系列 《甲骨文合集釋文》與 《甲骨文合集材料來源表》 甲骨文自1899年於河南安陽「問世」，至今已有百餘年歷史。在至對日抗戰前，曾進行多次考古挖掘，所獲甲骨超過十餘萬片。著錄、整理甲骨編纂成書，從早期《鐵雲藏龜》到《小屯第二本．殷墟文字．甲編》、《小屯第二本．殷墟文字．乙編》、《小屯第二本．殷墟文字．丙編》等書，都為甲骨文研究作了相當大的貢獻。但因各書收錄資料不一致，同一甲骨可能在兩本書中均有收錄。基於此，乃開始著手編纂《甲骨文合集》。 《甲骨文合集》自1978年開始付印出版後，至1980年已先後出版七冊。此時，胡厚宣先生開始編纂《甲骨文合集釋文》。自1980年11月決定《甲骨文合集釋文》編纂體例，初稿於1984年底完成。 總審校工作於1992年完成。由中國社會科學出版社出版，卻又發現《甲骨文合集釋文》繁體字、古字、隸定字和畫原形字較多，排版印刷十分困難；乃將全部釋文改為手寫影印，這個工作又花了兩年多，至1994年底完成。手寫影印稿完成之後，隨即進行繁複的校對工作。直到1999年，始正式出版。這樣的一部巨作，歷經艱辛，但對學術界有著十分重要的貢獻；由於它的出版，使得今日研究甲骨文之學者獲益良多，也促進了甲骨學的發展。 《甲骨文合集釋文》由中國社會科學出版社於1999年出版，共4冊。以《甲骨文合集》一書內容為基礎，按片號順序逐片作出釋文，並加以標點。釋文採用較為公認的說法隸定文字。而對於無法隸定的文字，則照原形摹畫，但不標明出處。至於出處，中國社會科學出版社另出版《甲骨文合集材料來源表》一書，為《甲骨文合集》之配套書，可供翻檢、對照。該書共三冊。分上、下編，上編又分為二冊。各冊之內容為：
甲骨文与市场营销 一、甲骨文 甲骨文，又称“契文”、“甲骨卜辞”或“龟甲兽骨文”。甲骨文记录和反映了商朝的政治和经济情况，主要指中国商朝后期（前14～前11世纪）王室用于占卜记事而在龟甲或兽骨上契刻的文字，殷商灭亡周朝兴起之后，甲骨文还延绵使用了一段时期。是中国已知最早的成体系的文字形式，它上承原始刻绘符号，下启青铜铭文，是汉字发展的关键形态。现代汉字即由甲骨文演变而来。 甲骨文距今已有三千余年，它不仅是研究我国文字源流的最早而有系统的资料，同时也是研究甲骨文书法重要的财富。从书法的角度审视，甲骨文已具备了书法的用笔、结字、章法三个基本要素。如果说钻木取火标志着人类告别了茹毛饮血的野蛮岁月，那么文字的出现就意味着人类走出了结绳记事的洪荒年代。甲骨文的发现，正是照亮中华文明的一盏明灯。甲骨文不仅仅是以个文明的符号、文化的标志，它还印证了包括《史记》在内的一系列文献的真实，把有记载的中华文明史向前推进了近5个世纪。在世界四大古文字体系中，唯有以殷墟甲骨文为代表的中国古汉字体系，历经数千年的演变而承续至今，书写出了一部博大精深的中华文明史。目前，安阳殷墟共出土甲骨15万片，单字约4500个，其中约有1500个单字已被释读。3000多
年以来，甲骨文虽然经过了金文、篆书、隶书、楷书等不同书写形式的变化，但是以形、音、义为特征的文字和基本语法保留至今，成为今天世界上五分之一人口仍在使用的方块字，对中国人的思维方式、审美观产生了重要的影响，为中国书法艺术的产生与发展奠定了基础。 二、市场营销 市场营销又称为市场学、市场行销或行销学；市场营销是指个人或集体通过交易其创造的产品或价值，以获得所需之物，实现双赢或多赢的过程。它包含两种含义，一种是动词理解，指企业的具体活动或行为，这时称之为市场营销或市场经营；另一种是名词理解，指研究企业的市场营销活动或行为的学科，称之为市场营销学、营销学或市场学等。 美国市场营销协会认为市场营销是创造、沟通与传送价值给顾客，及经营顾客关系以便让组织与其利益关系人受益的一种组织功能与程序，是一种最直接有效的营销手段。菲利普·科特勒强调了营销的价值导向：市场营销是个人和集体通过创造并同他人交换产品和价值以满足需求和欲望的一种社会和管理过程。市场营销是指企业的这种职能：认识未满足的需要和欲望，估量和确定需求量大小，选择和决定企业能最好地为其服务的目标市场，并决定适当的产品、劳务和计划（或方案），以便为目标市场服务。 麦卡锡于1960年也对微观市场营销下了定义：市场营销是企业经营活动的职责，它将产品及劳务从生产者直接引向消费者或使用者