Microsoft Azure Administrator

How to become Microsoft Azure Administrator:

Azure Administrators manage the cloud services that span storage, networking, and compute cloud capabilities, with a deep understanding of each service across the full IT lifecycle. They take end-user requests for new cloud applications and make recommendations on services to use for optimal performance and scale, as well as provision, size, monitor and adjust as appropriate. This role requires communicating and coordinating with vendors. Azure Administrators use the Azure Portal and as they become more proficient they use PowerShell and the Command Line Interface.

Below Some Prerequisites to quick cover Azure Administrators role:

Azure Administrators start this role with experience on operating systems, virtualization, cloud infrastructure, storage structures, and networking.

Also you can starts from scratch those does not having any experience.

Understanding of on-premises virtualization technologies, including: VMs, virtual networking, and virtual hard disks.
Understanding of network configuration, including TCP/IP, Domain Name System (DNS), virtual private networks (VPNs), firewalls, and encryption technologies.
Understanding of Active Directory concepts, including domains, forests, domain controllers, replication, Kerberos protocol, and Lightweight Directory Access Protocol (LDAP).
Understanding of resilience and disaster recovery, including backup and restore operations.

Find below are the topics you should cover and do hands-on exercise Azure portal access:

For practice you can use the free subscriptions.

Administer Azure using the Azure portal, Cloud Shell, Azure PowerShell, CLI, and ARM templates.
Plan for, create, and scale virtual machines.
Implement Azure storage accounts, blob storage, Azure files, and shared access keys.
Configure virtual networks including planning, IP addressing, Azure DNS, and network security groups.
Configure data replication and backup files, folders, and virtual machines.
Configure intersite connectivity solutions like VNet Peering, VNet-to-VNet connections, Site-to-Site connections, and ExpressRoute.
Manage network traffic using service endpoints, network routing choices, Azure load balancer, Azure Traffic Manager, and Content Delivery Network.
Manage subscriptions, accounts, users, groups, and billing. Implement Azure policies.
Implement Azure Active Directory and Azure Active Directory Connect.
Secure identities with MFA, Azure AD Identity Protection, AD Join, and Self-Service Password Reset.
Share data using the Import and Export service, Data Box, and File Sync.
Monitor Azure infrastructure with Azure Monitor, Azure alerts, Log Analytics, and Network Watcher.

***************************Happy Learning*****************************

Move physical Logs to other dbspace:

Overview:

When the database server initializes disk space, it places the physical log in the root dbspace. The initial size of the physical log is set by the PHYSFILE configuration parameter.

After initialize the database server for the first time, you can change the size or location of the physical log with the onparams utility.

To improve performance (specifically, to reduce the number of writes to the root dbspace and minimize disk contention), you can move the physical log out of the root dbspace to another dbspace, preferably to a disk that does not contain active tables or the logical-log files. For best performance, create the plogspace to store the physical log and allow the database server to expand the size of the physical log as needed to improve performance.

Run below commands to find out Physical log space:

$onstat –c |grep ^PHYS

$ oncheck -pe physdbs

First create a chunk for new dbspace:

$cd /Informix/storage/IDS

$touch physdbs

$chmod 660 physdbs

Create a new dbspace and move the physical logs:

$onspaces -c -d physdbs -o -s 512000 -p <path_to_chunks>/physdbs

$ onparams -p -s 400000 -d physdbs

$ ontape -s -L 0

Note: Size is in kb.It is advisable to use the values from the online.log to set the size of the physical log or increase this a little bit more. Different values in the online.log are due to the differing loads at the time the log is written.

Confirm the changes have been applied but running the following and checking the results:

$oncheck -pe physdbs

$onstat –c |grep ^PHYS

Find below difference between Plogspace and dbspace:

dbspace (vs) plogspace: When the physical log is in plogspace, the DB server increases the size of the physical log as needed to improve performance.

When the physical log is in dbspace, you must manually increase the size of the physical log.

To move the physical log to a dbspace, run the onparams -p -s command or the SQL administration API admin() or task() function with the create dbspace argument.

The following example changes the size and location of the physical log. The new physical-log size is 500 KB, and the log is in the dbspace11 dbspace:

onparams -p -s 500 -d dbspace11

*********Happy Learning*************

Informix DBA

Best Practices for Informix Database Administrator

This Course will focus on best practices for Informix DBA:

Informix Products Overview
Informix Architecture – Memory, CPU, Disk Requirements
Planning an Informix Install
Installing Informix
Software Directory Structure
Using Informix SQL
Monitoring tools
Monitoring configuration
Monitoring Instance activity
Monitoring database activity
Monitoring session activity
Monitoring performance
Backup and Recovery
High availability
Migration
Upgradetion

.................
.................
.................
...........Etc.

Email to:thedbaportfolio@gmail.com

Informix Database Operating Mode:

Informix Database Server Operating Mode:

Below are the four principal modes of operation of the database server:

OFFLINE <==> Quiescent <==> Single User <==> ONLINE

ONLINE: Users can connect with the database server and perform all database activities. This is normal operating mode of the database server.

OFFLINE: When the database server is not running. No shared memory is allocated.Only the administrator (user informix) can change from this mode to another mode.

Administration mode: Single user modeThis option brings the database server to administration mode, allowing the informix user all functions including the issuance of SQL and DDL commands. The -j -U option enables the DBSA to designate specific users (in addition to the informix user) to access the database server.

One or more users who have administration mode access User informix or a DBSA can dynamically give one or more specific users the ability to connect to the database server in administration mode through the onmode -j command, the oninit -U command, or the ADMIN_MODE_USERS configuration parameter.

Other users can view database-server status information, but they cannot access the database server.

Quiescent mode: Database-server processes are running and shared-memory resources are allocated.only administrators can access the database server to perform maintenance functions that do not involve the execution of SQL and DDL statements.

Other users can view database-server status information, but they cannot access the database server.

In addition, the database server can also be in one of the following modes:

Read-only mode is used by the secondary database server in a data replication environment. An application can query a secondary database server that is in read-only mode, but the application cannot write to a read-only database.
Recovery mode is transitory. It occurs when the database server performs fast recovery or recovers from a system archive or system restore. Recovery occurs during the change from offline to quiescent mode.
Shutdown mode is transitory. It occurs when the database server is moving from online to quiescent mode or from online (or quiescent) to offline mode. For the current users access the system, but no new users are allowed access.

After shutdown mode is initiated, it cannot be canceled.

Below Matrix are various commands to switch the database Mode:

	Online	Offline	Quiescent	Single/Admin
Online	--	onmode -ky (or) onmode -k	Gracefully: onmode –s (or) onmode –sy Immediate: onmode –u (or) onmode -uy	onmode –j
Offline	oninit -v (or) oninit -yv	--	oninit –s	oninit –j
Quiescent/ Maintenance	onmode -m	onmode –ky (or) onmode -k	--	onmode –j
Single User / Administrative	onmode -m	onmode -k	onmode -s (graceful) onmode -u (Immediate)	--

Move Logical Logs from the root dbspace to another dbspace:

Overview:

The database server creates the logical log files and the physical log in the root dbspace (rootdbs) when the instance is first initialized. After the intance is initialized, it is possible to move the logical logs to another dbspace. There are several reasons to move the logical logs. It may be required to utilize more space for logical logs than is available within the root dbspace. It is possible to improve performance by moving the logical log files to a dbspace on a disk not shared by active tables or by the physical log, reducing the number of writes to that disk and minimizing contention.

Run below commands to find out Logical log space details

$onstat c|grep ^LOG
$oncheck -pe|more

create a new dbspace for logical logs

Create a new chunk

$touch logspace1
$chmod 660 logspace1
create a new dbspace:
onspaces -c -d logspace1 -p /informix/storage/ids/logspace1 -o 0 -s 200000

To display existing log files information

$onstat -l

Add logical logs to the new dbspace(logspace1)

Syntax:

Run the command to create a logical log in the other dbspace once for each log to be added:

onparams -a -d dbspace -s size

where dbspace is the dbspace to create the logs in, and size is the size of the log in kilobytes.

onparams -a -d logspace1 -s 10000