AW command

The syntax of the AW command varies depending on the task that you want to perform.

Notes

When a program named TRIGGER_AW exists in the analytic workspace, the execution of any AW ATTACH, AW CREATE, AW DELETE, or AW DETACH statement automatically executes that program. See "Trigger Programs" and TRIGGER_AW, for more information.

When an AW ATTACH statement executes Oracle OLAP checks for other programs as well. See "Programs Executed When Attaching Analytic Workspaces" for more information.

AW ALIASLIST

The AW ALIASLIST command assigns or deletes one or more workspace alias for the specified attached workspace or, when no workspace is specified, for the current workspace. ALIAS indicates that the alias or aliases should be assigned, and UNALIAS indicates that the alias or aliases should be deleted.

Syntax

AW ALIASLIST [workspace] {ALIAS|UNALIAS} alias1, alias2, ...

Arguments

workspace

The name of the analytic workspace. You can specify either a workspace name or a workspace alias, depending on the keywords you are using.

ALIAS

Assigns one or more workspace alias for the specified attached workspace or, when no workspace is specified, for the current workspace. ALIAS indicates that the alias or aliases should be assigned, and UNALIAS indicates that the alias or aliases should be deleted.

All aliases for a given workspace are automatically deleted when you detach a workspace. Therefore, each time you attach an unattached workspace, you must reassign its aliases.

UNALIAS

Deletes one or more workspace alias for the specified attached workspace or, when no workspace is specified, for the current workspace.

alias1

alias2

When you assign an alias, keep in mind the following rules for workspace aliases: Aliases can contain only letters, numerals, and underscores; they cannot begin with a numeral; they cannot be reserved words in the OLAP DML; and they can be no more than 26 characters in length. (Use RESERVED to identify reserved words.) All characters must come from the database character set.

Notes

All aliases for a given workspace are automatically deleted when you detach a workspace. Therefore, each time you attach an unattached workspace, you must reassign its aliases.

Your session does not have to have a current workspace. When you start Oracle OLAP without specifying a workspace name, the EXPRESS workspace will be first on the list, but there is no current workspace until you specify one with the AW ATTACH statement. (You can make the EXPRESS workspace current by specifying its name in the AW ATTACH statement.)

When your database is installed with the OLAP option, the EXPRESS workspace is always attached in read-only mode in your session. It never automatically becomes the current workspace, even when it is the first or only workspace in your workspace list, because it is for internal use by Oracle OLAP. You can make the EXPRESS workspace the current workspace by explicitly attaching it, but this is not recommended. You cannot detach the EXPRESS workspace.

Examples

AW ALIASLIST scott.demo ALIAS sdemo

AW ALIASLIST demo ALIAS mydemo

AW ALLOCATE

The AW ALLOCATE command allocates space for your workspace.

Syntax

AW ALLOCATE n [K, M, or G] [workspace]

Arguments

n

The amount of space to allocate.

workspace

The name of the analytic workspace. You can specify either a workspace name or a workspace alias.

AW ATTACH

The AW ATTACH command attaches a workspace to your session. Oracle OLAP makes the specified workspace the current one. Previously attached workspaces move down in the list of attached workspaces to make room for the new current one at the top of the list.

When you attach more than one workspace, the code and data in all the attached workspaces are available during your session. The current workspace is first on the workspace list, which Oracle OLAP keeps for your session.

Syntax

AW ATTACH workspace  -

     [ONATTACH [progname]|NOONATTCH] -

     [RO|RW|RWX|MULTI] [WAIT|NOWAIT] -

     [AUTOGO [progname]|NOAUTOGO] -

     [AFTER workspace|BEFORE workspace|LAST|FIRST] -

     [PASSWORD password]

Arguments

workspace

The name of the analytic workspace. When you use the ATTACH keyword to attach a workspace that is not already attached, you must specify the workspace name. Again this is because no alias is assigned. However, when you use the ATTACH keyword on an already attached workspace (for example, in order to change its position in the workspace list), you can use an assigned alias

ONATTCH [progname]

An Onattach program automatically executes when the workspace is started:

• When you specify the ONATTCH keyword without following it with a program name, Oracle OLAP looks in the workspace for a program named ONATTACH and executes it if it exists. This syntax is provided for clarity in your programs. You can get the same results by not specifying ONATTACH.

• When you specify the ONATTCH keyword and you follow it with a program name, Oracle OLAP looks in the workspace for a program of that name. When it exists, Oracle OLAP executes that program, even when a program named ONATTACH exists in the workspace. See "Programs Executed When Attaching Analytic Workspaces" for more information.

NOONATTACH

Specifying NOONATTACH indicates that when a program named ONATTACH exists in the workspace, Oracle OLAP should not execute that program.

AUTOGO progname

When you do not specify progname, the AUTOGO clause automatically runs the program specified a program named AUTOGO if one exists in the attached workspace. When you do specify progname, the AUTOGO clause automatically runs the specified program in the attached program. See "Programs Executed When Attaching Analytic Workspaces" for more information.

NOAUTOGO

Specifying NOAUTOGO indicates that there is no Autogo program. This syntax is provided for clarity in your programs. You can get the same results by not specifying AUTOGO progname.

RO

Specifies that the workspace is attached in read-only access mode. (Default) Users can make private changes to the data in the workspace to perform what-if analysis but cannot commit any of these changes.

A workspace that is attached read-only can be accessed simultaneously by several sessions. The read-only attach mode is compatible with the read/write and multiwriter access mode. A user can attach an analytic workspace in read-only mode when other users have the workspace attached in either read/write and multiwriter access mode. Likewise, a user cannot attach an analytic workspace in read/write exclusive mode when another user has it attached in read-only mode. When you attach a workspace with read-only access, Oracle OLAP executes a program called PERMIT_READ, when it finds one in the workspace.

RW

Specifies that the workspace is attached in read/write access mode. Only one user can have an analytic workspace open in read/write at a time. The user has to commit either all or none of the changes made to the workspace.

A workspace that is attached read/write non-exclusive can be accessed simultaneously by several sessions. The read/write non-exclusive attach mode is only compatible with the read-only access mode. A user can attach an analytic workspace in read/write mode when other users have the workspace attached in read-only mode; however, a user not attach an analytic workspace in read/write mode when another user has it attached in any other mode. Likewise, a user cannot attach an analytic workspace in any mode other than read-only when another user has it attached in read/write non-exclusive mode. When you attach a workspace with read/write access, Oracle OLAP executes a program called PERMIT_WRITE, when it finds one in the workspace. See "Permission Programs".

RWX

Specifies that the workspace is attached in read/write exclusive access mode. Only one user can have an analytic workspace open in read/write exclusive at a time. The user has to commit either all or none of the changes made to the workspace.

A workspace that is attached read/write exclusive cannot be accessed by any other sessions.  The read/write exclusive attach mode is not compatible with any other access modes. A user cannot attach an analytic workspace in read/write exclusive mode when another user has it attached in any mode. Likewise, a user cannot attach an analytic workspace in any other mode when another user has it attached in read/write exclusive mode. When you attach a workspace with read/write access, Oracle OLAP executes a program called PERMIT_WRITE, when it finds one in the workspace. See "Permission Programs".

MULTI

Specifies that the workspace is attached in multiwriter access mode. A workspace that is attached in multiwriter mode can be access simultaneously by several sessions. In multiwriter mode, users can simultaneously modify the same analytic workspace in a controlled manner by specifying specify the attachment mode (read-only or read/write) for individual variables, relations, valuesets, and dimensions.

See: Table 8-1, "Statements for Managing Objects When Attached in Multiwriter Mode" for a list of the OLAP DML statements that you use to manipulate objects in an analytic workspace that is attached in multiwriter mode,.

The multiwriter attach mode is only compatible with read-only and multiwriter modes. A user cannot attach an analytic workspace in multiwriter mode when another user has it attached in read/write or exclusive modes. Likewise, a user cannot attach an analytic workspace in read/write or exclusive mode when another user has it attached in multiwriter mode.

WAIT

NOWAIT

Specifies whether Oracle OLAP waits for a workspace to become available for access when you request access to a workspace that is being used with read/write exclusive access or when you request read/write access to a workspace that is already being used with read/write non-exclusive access. NOWAIT (the default) causes Oracle OLAP to produce an error message indicating that the workspace is unavailable. When you specify WAIT, Oracle OLAP will wait for the workspace to become available for access. The number of seconds that Oracle OLAP will wait for access depends on the value of the Oracle OLAP option AWWAITTIME. For more information, see AWWAITTIME and "Workspace Sharing".

FIRST

Makes the workspace you are attaching the current workspace in the workspace list. (Default)

LAST

Puts the workspace after the current workspace in the workspace list and before the EXPRESS workspace. When there are other workspaces attached before the EXPRESS workspace, the specified workspace is attached after them. When there are no workspaces before the EXPRESS workspace, LAST makes the specified workspace the current one. LAST ignores any workspaces after the EXPRESS workspace.

AFTER workspace

BEFORE workspace

Let you specify the position in the workspace list of the newly attached workspace relative to a workspace that is already attached. Use AFTER, rather than LAST, to attach a workspace after the EXPRESS workspace. When specifying BEFORE puts the workspace first, the workspace becomes the current one.

The order of the workspace list determines the order in which workspaces will be searched when Oracle OLAP looks for programs or objects named in programs.

PASSWORD password

Specifies a password to be checked in a permission program in order to give or deny access to the workspace being attached. See "Permission Programs".

Notes

Attaching more than one workspace to your session provides access to programs and data in all of the attached workspaces. You can look at and change data or edit programs in any of the workspaces. As long as the workspace is not attached read-only, you can update your changes.

Naming objects requires more care when you attach more than one workspace. When you request an object by name, either with a DESCRIBE statement or by referring to it in a statement or program, Oracle OLAP searches all the active workspaces in order until it finds the named object. When you intend to use several workspaces together, do not give the same name to objects in different workspaces, unless you are prepared to use qualified object names.

The names of all attached workspaces are kept on the workspace list. You can view the list using AW LIST.

When you are attached in multiwriter mode, you use the OLAP DML statements listed in Table 8-1 to manipulate analytic workspace objects.

When you attach a workspace, Oracle OLAP looks for and executes the following programs in the order indicated:

1. Onattach program. A program that Oracle OLAP looks for and executes when you attach an analytic workspace using an AW ATTACH statement in either of the following situations:

   • When you attach an analytic workspace that contains a program named ONATTACH and you do not include the NOONATTCH keyword in the AW statement or when the AW statement includes an ONATTACH clause that does not specify a program name, Oracle OLAP executes the ONATTACH program.

   • When the AW statement includes an ONATTCH clause that specifies a program name, Oracle OLAP looks in the workspace for a program of that name. When it exists, Oracle OLAP executes that program.

2. Permission programs. Programs that Oracle OLAP looks for and executes varies depending on the attachment mode specified in the AW ATTACH statement:

   1. When you request that an analytic workspace be attached in read-only mode, Oracle OLAP checks for a program named PERMIT_READ.

   2. When you request that an analytic workspace be attached in exclusive or non-exclusive read/write mode, Oracle OLAP checks for a program named PERMIT_WRITE.

3. Autogo program. A program that Oracle OLAP looks for and executes when you attach an analytic workspace using an AW ATTACH statement with the AUTOGO clause.

4. TRIGGER_AW program. A trigger program that you create and that Oracle OLAP checks for by name when an AW command executes.

Reattaching an attached workspace with a AW ATTACH workspace statement does not cause Oracle OLAP to bring a new copy of the workspace into working memory. Instead, Oracle OLAP takes the following actions:

1. Makes the workspace the current workspace.

2. Runs an Autogo program, when you specify the AUTOGO keyword

However, when you have made any changes to data during the session, they are not discarded when you reattach an active workspace. Furthermore, current aliases for the workspace are not changed.

You cannot attach a workspace that is in your schema and whose name is the same as an assigned alias. Similarly, you cannot assign an alias that duplicates the name of an attached workspace that is in your schema. Furthermore, you cannot assign the same alias to two attached workspaces.

In an AW DELETE statement, when you specify a workspace name (for a workspace that is not attached) and the name is the same as an assigned alias, Oracle OLAP interprets the name as an alias and reports an error.

When your database is installed with the OLAP option, the EXPRESS workspace is always attached in read-only mode in your session. It never automatically becomes the current workspace, even when it is the first or only workspace in your workspace list, because it is for internal use by Oracle OLAP. You can make the EXPRESS workspace the current workspace by explicitly attaching it, but this is not recommended. You cannot detach the EXPRESS workspace.

Keep the following points in mind when working with permission programs.

You can specify permission to access workspace objects with PERMIT statements. You can specify PERMIT statements, and the values of the permission conditions on which permission is based, in the workspace permission programs PERMIT_READ and PERMIT_WRITE. All the objects referred to in the workspace permission programs or in the permission expressions must exist within the same workspace. (See PERMIT.)

You create the workspace permission programs as user-defined Boolean functions in the workspace to which you want to control access. PERMIT_READ must be the name of the program for attaching read-only. PERMIT_WRITE must be the name of the program for attaching read/write. When a workspace permission program executes, it must return YES in order for the workspace to be attached.

When you have workspace permission programs defined in workspaces that are currently attached, Oracle OLAP executes the one in the workspace that you are attaching. However, when you have workspace permission programs in more than one currently attached workspace, you must take special care when you edit them or use them in any other way, to ensure that you access the appropriate version.

When you specify a password when attaching the workspace, it is passed as an argument to the workspace permission program.

When you export PERMIT_READ or PERMIT_WRITE programs which are hidden, they are empty when imported. Additionally, when you outfile PERMIT_READ or PERMIT_WRITE programs which are hidden, then they are empty when infiled.

To protect a workspace from inadvertent changes, you can specify RO access when attaching it. You can use a read-only workspace in the same way as an ordinary workspace; you can even make changes to it during your session. However, you cannot save the changes in your session by updating. The UPDATE will have no effect. This protects data you are sure you do not want to change.

Unless the workspace is already attached exclusive and your user ID has the appropriate access rights, you can get read-only access to a workspace, no matter how many other users are using it. When another user has read/write access and uses the UPDATE and COMMIT statements, your view of the workspace does not change. However, you can access their committed changes by detaching the workspace and attaching it again.

Examples

DEFINE PERMIT_READ PROGRAM BOOLEAN
PROGRAM
SHOW 'permit_read program executing'
AW LIST
RETURN YES
END
 
DEFINE PERMIT_WRITE PROGRAM BOOLEAN
PROGRAM
SHOW 'permit_write program executing'
AW LIST
RETURN YES
END
 
DEFINE ONATTACH PROGRAM BOOLEAN
PROGRAM
SHOW 'onattach program executing'
AW LIST
RETURN YES
END
 
DEFINE MYATTACH PROGRAM BOOLEAN
PROGRAM
SHOW 'myattach program executing'
AW LIST
RETURN YES
END
 
DEFINE AUTOGO PROGRAM 
PROGRAM
SHOW 'autogo program executing'
AW LIST
END
 

DEFINE onattach PROGRAM
PROGRAM
AW ATTACH expenses RW AFTER analysis 
AW ATTACH revenues RW AFTER analysis 
END

AW ATTACH analysis 

ANALYSIS  R/W CHANGED   XUSER.ANALYSIS
REVENUE   R/W UNCHANGED XUSER.REVENUES
EXPENSES  R/W UNCHANGED XUSER.EXPENSES
EXPRESS   R/O UNCHANGED SYS.EXPRESS

AW CREATE

The AW CREATE command creates a new workspace and make it the current workspace in your session. It is important to note that Oracle OLAP automatically executes a COMMIT as part of its procedure for creating a workspace. Previously attached workspaces move down in the list of attached workspaces to make room for the new one at the top of the list. Oracle suggests that you use the TABLESPACE argument to create your workspace in a tablespace that has been prepared for this purpose. Ask your DBA which tablespace you should use.

Syntax

AW CREATE workspace [position] [UNPARTITIONED|PARTITIONS n] -

     [SEGMENTSIZE n [K, M, or G]] [TABLESPACE tblspname]

where position specifies the workspace's position in the workspace list and is one of the following values. (FIRST is the default.)

AFTER workspace

BEFORE workspace

LAST

FIRST

Arguments

workspace

The name of the analytic workspace. You must specify the name. You cannot specify an alias because no alias is assigned when you are creating. When you create a workspace, keep in mind the following rules for workspace names: Workspace names can contain only letters, numerals, and underscores; they cannot begin with a numeral; they cannot be reserved words in the DML; and they can be no more than 26 characters in length. (Use RESERVED to identify reserved words.) All characters must come from the database character set.

FIRST

Makes the workspace you are attaching the current workspace. (Default)

LAST

Puts the workspace after the current workspace and before the EXPRESS workspace. When there are other workspaces attached before the EXPRESS workspace, the specified workspace is attached after them. When there are no workspaces before the EXPRESS workspace, LAST makes the specified workspace the current one. LAST ignores any workspaces after the EXPRESS workspace.

AFTER

BEFORE

Specify the position of the newly attached workspace relative to a workspace that is already attached. Use AFTER, rather than LAST, to attach a workspace after the EXPRESS workspace. When specifying BEFORE puts the workspace first, the workspace becomes the current one.

The order of the workspace list determines the order in which workspaces will be searched when Oracle OLAP looks for programs or objects named in programs.

UNPARTITIONED

Specifies that the relational table that is the analytic workspace is not a partitioned table.

partitionS n

Specifies that the relational table that is the analytic workspace is a hash partitioned table with n partitions. Specifying a value of 0 (zero) for n is the same as specifying UNPARTITIONED. The default value of n is 8.

SEGMENTSIZE n [K, M, or G]

With the CREATE keyword, this argument sets the maximum size of each segment for the workspace being created. When you do not specify K, M, or G, the value you specify for n is interpreted as bytes. When you specify K, M, or G after the value n, the value is interpreted as kilobytes, megabytes, or gigabytes, respectively.

TABLESPACE  tblspname

Specifies the name of an Oracle Database tablespace in which the analytic workspace is created.

Notes

You can add security to analytic workspaces at several levels:

• At the relational table level.

• At the analytic workspace level and workspace object level as described in "Restricting Accessing Using Analytic Workspace Attachment Modes" .

• At the analytic workspace object level and value level as described in "Restricting Access Using OLAP DML Permission Programs" .

An analytic workspace is a multidimensional data source that is stored as a relational table of LOBs. The name of the relational table that is the analytic workspace is AW$ followed by the OLAP DML name of the analytic workspace.

When you first create an analytic workspace using an OLAP DML AW CREATE statement, you are the only user who has access that workspace. When you want others to use the workspace, you must give them access to the relational table that is the analytic workspace use an SQL GRANT statement:

• To give read access to another user, execute a statement like the following one in SQL. In this example, the workspace name is demo and the user's name is Scott.

  GRANT SELECT ON aw$demo TO Scott
  

• To give write access to another user, execute a SQL statement like the following one.

  GRANT UPDATE ON aw$demo TO Scott
  

As in any SQL GRANT statement, you can specify a group or role instead of a user.

When you attach an analytic workspace using the AW ATTACH statement, the mode that you attach it in determines the access that have to the analytic workspace objects:

• Read-only mode — When an analytic workspace is attached in read-only access mode, users can make private changes to the data in the workspace to perform what-if analysis, but cannot commit any of these changes.

• Read/write nonexclusive mode—Only one user can have an analytic workspace attached in read/write nonexclusive mode at a time. The user has to commit either all or none of the changes made to the workspace.

• Read/write exclusive mode—Only one user can have an analytic workspace attached in read/write exclusive at a time. The user has to commit either all or none of the changes made to the workspace.

• Multiwriter mode —A workspace that is attached in multiwriter mode can be accessed simultaneously by several sessions. In multiwriter mode, users can simultaneously modify the same analytic workspace in a controlled manner by specifying the attachment mode (read-only or read/write) for individual objects.

  When users first attach an analytic workspace in multiwriter mode, all objects in the workspace are read-only. Users can make private changes to the data in the workspace to perform what-if analysis but you cannot update or commit any of these changes. Using the OLAP DML statements described in Table 8-1, "Statements for Managing Objects When Attached in Multiwriter Mode", users manipulate the attachment mode of individual objects (for example, change the a variable from read-only to write access).

Permission programs are programs that you write that give permission to users to access workspace data. Permission programs do not exist within an analytic workspace unless you define and write them as described in "Permission Programs".

When a user attaches an analytic workspace, Oracle OLAP checks to see if a permission program that is appropriate for the attachment mode exists. (The permission program for each attachment mode must have a particular name as outlined in Table 8-2, "Names of Permission Programs for Different Attachment Modes".) When an appropriate permission program exists, Oracle OLAP executes the program. When a user specifies a password when attaching the analytic workspace, then the password is passed as an argument to the permission program for processing.

Permission programs are not the only programs that are executed when a user attaches to an analytic workspace. For more information, see "Startup Programs".

Examples

AW CREATE mywork

AW DELETE

The AW DELETE command deletes the specified workspace from the database. It is important to note that Oracle OLAP automatically executes a COMMIT as part of its procedure for deleting a workspace. The DELETE keyword executes successfully only when no user has the workspace attached. Therefore, detach the workspace before executing this statement.

Syntax

AW DELETE workspace

Arguments

workspace

The name of the analytic workspace. You must specify the name; you cannot specify an alias.

Notes

When you attempt to delete an unattached workspace and the name is the same as an assigned alias, Oracle OLAP interprets the name as an alias and reports an error.

Examples

AW DELETE mywork

AW DETACH

The AW DETACH command removes a workspace from the workspace list. When you remove the first workspace, the second workspace becomes the current workspace (unless it is the EXPRESS workspace). When you detach a workspace, changes that were made before an UPDATE was issued remain in the database and become permanent with the next COMMIT. When changes were made after the UPDATE was issued, they are discarded.

Syntax

AW DETACH workspace

Arguments

workspace

The name of the analytic workspace. You can specify either a workspace name or a workspace alias, depending on the keywords you are using.

Notes

You cannot detach the EXPRESS workspace.

Examples

AW DETACH expense 

AW LIST

The AW LIST command sends to the current outfile a list of the active workspaces, along with their update status.

Syntax

AW LIST

Notes

The first workspace in the list is the current workspace, unless you do not have a current workspace. The meaning of the update status, CHANGED or UNCHANGED, depends on whether the workspace is attached with read/write or read-only access and whether or not the workspace is being shared with other users. The update status displayed by AW LIST is as follows:

• An unshared workspace in read/write mode -- The update status is CHANGED when you have made changes since attaching the workspace or since your last update.

• An unshared workspace in read-only mode -- The status is always UNCHANGED because you cannot update it.

• A shared workspace in read/write mode -- The status is CHANGED when you have made changes since attaching the workspace or since your last update. This is the same as for an unshared workspace in read/write mode.

• A shared workspace in read-only mode -- The status is CHANGED when another user has updated it since you accessed it. To access the new objects or data, you must detach and reattach the workspace after the other user commits his or her changes. As long as you keep the workspace attached, your view of the workspace remains unchanged.

The name of the current workspace is first on the workspace list and is the name returned by the AW(NAME) function. (See AW function for details.) The NAME dimension includes only the objects in the current workspace. Programs such as AWDESCRIBE and LISTBY list only objects in the current workspace. When a workspace is active but not current, you can change and update its data, edit and run its programs, and modify its objects.

When your database is equipped with the OLAP option, the EXPRESS workspace is always attached in read-only mode in your session. It never automatically becomes the current workspace, even when it is the first or only workspace in your workspace list, because it is for internal use by Oracle OLAP. You can make the EXPRESS workspace the current workspace by explicitly attaching it, but this is not recommended. You cannot detach the EXPRESS workspace.

Examples

Assume that you have just connected to Oracle OLAP using the OLAP Worksheet. You issue an AW LIST statement that returns a value showing that the only attached analytic workspace is EXPRESS.

AW LIST
EXPRESS   R/O UNCHANGED SYS.EXPRESS
 

Now you create a new analytic workspace and issue another AW LIST statement. You can see that both the EXPRESS analytic workspace and the newly created analytic workspace are attached.

AW CREATE myaw
AW LIST
MYAW      R/W UNCHANGED MYNAME.MYAW
EXPRESS   R/O UNCHANGED SYS.EXPRESS
 

AW SEGMENTSIZE

The AW SEGMENTSIZE command sets up a workspace for multiple segments.

Syntax

AW SEGMENTSIZE n [K, M, or G] [workspace]

Arguments

workspace

The name of the analytic workspace. You can specify either a workspace name or a workspace alias, depending on the keywords you are using.

SEGMENTSIZE n [K, M, or G] [workspace]

Sets the maximum size of each segment for a specified workspace or, when no workspace is specified, for the current workspace.

When the current workspace already has several segments, setting SEGMENTSIZE affects only the most recent one and has no effect on previous ones. Previous segments may have various sizes, determined by the SEGMENTSIZE setting at the time each one was created. When you do not specify K, M, or G, the value you specify for n is interpreted as bytes. When you specify K, M, or G after the value n, the value is interpreted as kilobytes, megabytes, or gigabytes, respectively.