Hi,

Anyone knows what these are ues for? arserverd will accept values on these
variables.

Oracle-Bulk-Fetch-Count:
Oracle-All-Upper-Index:
Oracle-Upper-Index:
Clustered-Index:

--
Jarl Groneng

__

You may also control your subscription options, including UNSUBSCRIBE, at www.ARSLIST.org

Hi Jarl,

Interesting queries, one which Peregrine may be able shed some light on
after a bit of searching, here a couple of comments I have which may or may
not be entirely accurate and you probably have taught these yourself:

Oracle-Bulk-Fetch-Count:
========================

This is probably to do with the following situation:

when a client requests many records [thousands] and the remedy server does
not hand them back to the client all in one go [from a feed from the oracle
server process] but uses a process of chunking to the client which involves
a steady stream of retrieval from the oracle server process


The other two Oracle related ones I didn't see in the 5 manuals nor did a
'strings *|grep -i oracle|more' of the remedy5 bin directory report any such
match.

However the same command on the remedy4 binaries did return these matches
and in actual fact alot more in the strings output so just maybe these are
no longer used with remedy 5??? I didn't see them in the 4 manuals. Mind you
I only had a quick glance

Clustered-Index:
================

I know the doc doesn't mention this is limited to a specific database but I
reckon it is
sybase/sql related and not oracle/informix. With sybase/sql you can have at
most 1 clustered index per table and the entryid[c1] or in the dd id [such
as actlinkid] are clustered. Here is some info from the sql books online

Books on line:

Using Clustered Indexes
A clustered index determines the physical order of data in a table. A
clustered index is analogous to a telephone directory, which arranges data
by last name. Because the clustered index dictates the physical storage
order of the data in the table, a table can contain only one clustered
index. However, the index can comprise multiple columns (a composite index),
like the way a telephone directory is organized by last name and first name.

A clustered index is particularly efficient on columns that are often
searched for ranges of values. After the row with the first value is found
using the clustered index, rows with subsequent indexed values are
guaranteed to be physically adjacent. For example, if an application
frequently executes a query to retrieve records between a range of dates, a
clustered index can quickly locate the row containing the beginning date,
and then retrieve all adjacent rows in the table until the last date is
reached. This can help increase the performance of this type of query. Also,
if there is a column(s) that is used frequently to sort the data retrieved
from a table, it can be advantageous to cluster (physically sort) the table
on that column(s) to save the cost of a sort each time the column(s) is
queried.

Clustered indexes are also efficient for finding a specific row when the
indexed value is unique. For example, the fastest way to find a particular
employee using the unique employee ID column emp_id is to create a clustered
index or PRIMARY KEY constraint on the emp_id column.



Note PRIMARY KEY constraints create clustered indexes automatically if no
clustered index already exists on the table and a nonclustered index is not
specified when you create the PRIMARY KEY constraint.


Alternatively, a clustered index could be created on lname, fname (last
name, first name), because employee records are often grouped and queried in
this way rather than by employee ID.

Considerations
It is important to define the clustered index key with as few columns as
possible. If a large clustered index key is defined, any nonclustered
indexes that are defined on the same table will be significantly larger
because the nonclustered index entries contain the clustering key. The Index
Tuning Wizard does not return an error when saving an SQL script to a disk
with insufficient available space. For more information about how
nonclustered indexes are implemented in Microsoft® SQL Server(tm) 2000, see
Nonclustered Indexes.

The Index Tuning Wizard can consume significant CPU and memory resources
during analysis. It is recommended that tuning should be performed against a
test version of the production server rather than the production server.
Additionally, the wizard should be run on a separate computer from the
computer running SQL Server. The wizard cannot be used to select or create
indexes and statistics in databases on SQL Server version 6.5 or earlier.

Before creating clustered indexes, understand how your data will be
accessed. Consider using a clustered index for:

Columns that contain a large number of distinct values.


Queries that return a range of values using operators such as BETWEEN, >,
>=, <, and <=.


Columns that are accessed sequentially.


Queries that return large result sets.


Columns that are frequently accessed by queries involving join or GROUP BY
clauses; typically these are foreign key columns. An index on the column(s)
specified in the ORDER BY or GROUP BY clause eliminates the need for SQL
Server to sort the data because the rows are already sorted. This improves
query performance.


OLTP-type applications where very fast single row lookup is required,
typically by means of the primary key. Create a clustered index on the
primary key.
Clustered indexes are not a good choice for:

Columns that undergo frequent changes
This results in the entire row moving (because SQL Server must keep the data
values of a row in physical order). This is an important consideration in
high-volume transaction processing systems where data tends to be volatile.

Wide keys
The key values from the clustered index are used by all nonclustered indexes
as lookup keys and therefore are stored in each nonclustered index leaf
entry.

If you manage to find out anything more concrete please let me know.

Regards,
Kevin

-----Original Message-----
From: Jarl Groneng [mailto:jarl.groneng@TELENOR.COM]
Sent: 22 January 2002 07:25
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Config values...


**

Hi,

Anyone knows what these are ues for? arserverd will accept values on these
variables.

Oracle-Bulk-Fetch-Count:
Oracle-All-Upper-Index:
Oracle-Upper-Index:
Clustered-Index:

--
Jarl Groneng

__________________
_____________


You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

__

You may also control your subscription options, including UNSUBSCRIBE, at www.ARSLIST.org

Here is the information I got back from Remedy support:


Oracle-Bulk-Fetch-Count:

When a search is performed against an Oracle database, by default, we pull
back the returned rows from the database in chunks of 50. By using this
parameter it is possible to change the number pulled back in a chunk to a
maximum of 100. The minimum is 1. This is a tuning parameter and there
will be tradeoffs in reducing or increasing this value. Typically we would
not expect you to change this value.

Oracle-All-Upper-Index:
Oracle-Upper-Index:

These are options that can be set in 'ardb.conf'. This file allows you to
control how tables and indexes are created by ARS. We build a clause to
append to the end of the CREATE TABLE or CREATE INDEX statements based on
what is in this file (if it exists). These options allow you to specify that
the index will be based an uppercase value for a column. The 'All-Upper'
option will tell ARS that all indexes for this schema/table should be
created against the UPPER value of a field/column. 'Oracle-Upper-Index:'
specifies that the UPPER index is just for this specific index.


--
Jarl Groneng

> -----Original Message-----
> From: Kevin Murray [mailto:kevin.murray@FUSION.IE]
> Sent: 25. januar 2002 11:08
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: Config values...
>
>
> **
>
> Hi Jarl,
>
> Interesting queries, one which Peregrine may be able shed
> some light on
> after a bit of searching, here a couple of comments I have
> which may or may
> not be entirely accurate and you probably have taught these yourself:
>
> Oracle-Bulk-Fetch-Count:
> ========================
>
> This is probably to do with the following situation:
>
> when a client requests many records [thousands] and the
> remedy server does
> not hand them back to the client all in one go [from a feed
> from the oracle
> server process] but uses a process of chunking to the client
> which involves
> a steady stream of retrieval from the oracle server process
>
>
> The other two Oracle related ones I didn't see in the 5
> manuals nor did a
> 'strings *|grep -i oracle|more' of the remedy5 bin directory
> report any such
> match.
>
> However the same command on the remedy4 binaries did return
> these matches
> and in actual fact alot more in the strings output so just
> maybe these are
> no longer used with remedy 5??? I didn't see them in the 4
> manuals. Mind you
> I only had a quick glance
>
> Clustered-Index:
> ================
>
> I know the doc doesn't mention this is limited to a specific
> database but I
> reckon it is
> sybase/sql related and not oracle/informix. With sybase/sql
> you can have at
> most 1 clustered index per table and the entryid[c1] or in
> the dd id [such
> as actlinkid] are clustered. Here is some info from the sql
> books online
>
> Books on line:
>
> Using Clustered Indexes
> A clustered index determines the physical order of data in a table. A
> clustered index is analogous to a telephone directory, which
> arranges data
> by last name. Because the clustered index dictates the
> physical storage
> order of the data in the table, a table can contain only one clustered
> index. However, the index can comprise multiple columns (a
> composite index),
> like the way a telephone directory is organized by last name
> and first name.
>
> A clustered index is particularly efficient on columns that are often
> searched for ranges of values. After the row with the first
> value is found
> using the clustered index, rows with subsequent indexed values are
> guaranteed to be physically adjacent. For example, if an application
> frequently executes a query to retrieve records between a
> range of dates, a
> clustered index can quickly locate the row containing the
> beginning date,
> and then retrieve all adjacent rows in the table until the
> last date is
> reached. This can help increase the performance of this type
> of query. Also,
> if there is a column(s) that is used frequently to sort the
> data retrieved
> from a table, it can be advantageous to cluster (physically
> sort) the table
> on that column(s) to save the cost of a sort each time the
> column(s) is
> queried.
>
> Clustered indexes are also efficient for finding a specific
> row when the
> indexed value is unique. For example, the fastest way to find
> a particular
> employee using the unique employee ID column emp_id is to
> create a clustered
> index or PRIMARY KEY constraint on the emp_id column.
>
>
>
> Note PRIMARY KEY constraints create clustered indexes
> automatically if no
> clustered index already exists on the table and a
> nonclustered index is not
> specified when you create the PRIMARY KEY constraint.
>
>
> Alternatively, a clustered index could be created on lname,
> fname (last
> name, first name), because employee records are often grouped
> and queried in
> this way rather than by employee ID.
>
> Considerations
> It is important to define the clustered index key with as few
> columns as
> possible. If a large clustered index key is defined, any nonclustered
> indexes that are defined on the same table will be
> significantly larger
> because the nonclustered index entries contain the clustering
> key. The Index
> Tuning Wizard does not return an error when saving an SQL
> script to a disk
> with insufficient available space. For more information about how
> nonclustered indexes are implemented in Microsoft® SQL
> Server(tm) 2000, see
> Nonclustered Indexes.
>
> The Index Tuning Wizard can consume significant CPU and
> memory resources
> during analysis. It is recommended that tuning should be
> performed against a
> test version of the production server rather than the
> production server.
> Additionally, the wizard should be run on a separate computer from the
> computer running SQL Server. The wizard cannot be used to
> select or create
> indexes and statistics in databases on SQL Server version 6.5
> or earlier.
>
> Before creating clustered indexes, understand how your data will be
> accessed. Consider using a clustered index for:
>
> Columns that contain a large number of distinct values.
>
>
> Queries that return a range of values using operators such as
> BETWEEN, >,
> >=, <, and <=.
>
>
> Columns that are accessed sequentially.
>
>
> Queries that return large result sets.
>
>
> Columns that are frequently accessed by queries involving
> join or GROUP BY
> clauses; typically these are foreign key columns. An index on
> the column(s)
> specified in the ORDER BY or GROUP BY clause eliminates the
> need for SQL
> Server to sort the data because the rows are already sorted.
> This improves
> query performance.
>
>
> OLTP-type applications where very fast single row lookup is required,
> typically by means of the primary key. Create a clustered index on the
> primary key.
> Clustered indexes are not a good choice for:
>
> Columns that undergo frequent changes
> This results in the entire row moving (because SQL Server
> must keep the data
> values of a row in physical order). This is an important
> consideration in
> high-volume transaction processing systems where data tends
> to be volatile.
>
> Wide keys
> The key values from the clustered index are used by all
> nonclustered indexes
> as lookup keys and therefore are stored in each nonclustered
> index leaf
> entry.
>
> If you manage to find out anything more concrete please let me know.
>
> Regards,
> Kevin
>
> -----Original Message-----
> From: Jarl Groneng [mailto:jarl.groneng@TELENOR.COM]
> Sent: 22 January 2002 07:25
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Config values...
>
>
> **
>
> Hi,
>
> Anyone knows what these are ues for? arserverd will accept
> values on these
> variables.
>
> Oracle-Bulk-Fetch-Count:
> Oracle-All-Upper-Index:
> Oracle-Upper-Index:
> Clustered-Index:
>
> --
> Jarl Groneng
>
> ____
> ______________
> _____________
>
>
> You may also control your subscription options, including
> UNSUBSCRIBE, at
> www.ARSLIST.org
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
> **********************************************************************
>
> ____
> ___________________________
>
>
> You may also control your subscription options, including
> UNSUBSCRIBE, at www.ARSLIST.org
>

__

You may also control your subscription options, including UNSUBSCRIBE, at www.ARSLIST.org

Now, we test the arsystem on Chinese Environment. My customer require to use on Chinese and Korean.
Our ARSystem Server, Mid Tier, Web Server and DB Server is a Solaris 2.6.
The DataBase is Oracle 8.1.7 Server and its Character Set is Uni-Code.
We have some problems.
First, We want to key in Chines on Unix(Solaris 2.6). How can I set the Language. Please explain the details.

Next, When we test the ARSystem 5.0, we can not read and input chinese character on Windows 98 Internet Explorer
web browser for Chinese Version but we can read and input Chinese Character on Remedy User Tool. Have ever been
test the ARSystem 5.0 and Web Server. We expect the problem why the Appache Server is need additional pack.

Finally, Have you ever been test the ARSystem for both Tiwan and PRC(People Republic Chiana)?


-------------------------------------------------------------------
Yun-Taek Chung Adv. Systems Engineer
DataGate International Inc.
9F KOTEF Bldg, 35-3 Yoido-Dong, Tel: +82-2-761-0101
Youngdeungpo-Ku, Seoul, Korea Fax: +82-2-769-1855
#150-704 Email: roy@datagate.co.kr
http://www.datagate.co.kr
-------------------------------------------------------------------
N…
I@R 
隊[azg¬±¨º{.nÇ+‰·š®Éb²Ûh–+-±êï–+-±êï¾+-j+\¢f(ºf²j[(r‰í®‰r¢êì¹»®*mŠ‰è¦Ø¨žÈ§r[�Šx5%
H$HF­ÃE"ÈI:+