When using screen tool error cannot open your terminal /dev/pts/0 in Linux

Screen Tool Error

When using the screen tool you may be unable to start a screen session but instead encounter an error:

Logs:-

Cannot open your terminal '/dev/pts/0' - please check.

This is because another user (you) initiated the current terminal – you probably did a sudo su into the user you are now trying to run screen as, right?'

There are two ways to resolve this:

Sign out and properly connect / sign in as the user you wish to use.

Run script /dev/null to own the shell (more info over at Server Fault); then try screen again.

Important: Do not chmod the virtual terminal device like suggested at (way too many) places around the interwebs. This gives other users read and write access to the terminal session!

Microsoft launches smartphone app called Kaizala

KAIZALA

Microsoft today launched a new smartphone app called Kaizala. Microsoft Kaizala is meant for organizations and businesses to conduct group communications and manage work easily. Microsoft Kaizala is available for both iOS and Android users for free. Additionally, Kaizala Pro, the paid version for enterprises was also launched yesterday.

Microsoft today launched a new smartphone app called Kaizala. Microsoft Kaizala is meant for organizations and businesses to conduct group communications and manage work easily. Microsoft Kaizala is available for both iOS and Android users for free. Additionally, Kaizala Pro, the paid version for enterprises was also launched yesterday.

Every file shared within the group, particularly action cards can be commented on, liked, and shared by users. Groups created in Kaizala have a unique feature of adding members in bulk. Also, the limit of members in one group can go up to millions, as said by Anant Maheshwari, President, Microsoft India. 

Aimed at a mobile-centric world, Maheshwari clarifies that Kaizala is different from existing platforms like Microsoft Teams and Office 365. Both of these products are desktop friendly, and aimed at businesses respectively. Keeping India’s poor internet connectivity in mind, Kaizala is optimized to work offline and on 2G network as well. Maheshwari also says that this is a ‘Made for India’ product, and there are no plans for a global launch yet.

Speaking about Microsoft Kaizala Pro, it can be purchased at a price of Rs 130 per month. It comes with more features like user and group management, system integration and automation using Microsoft Kaizala APIs. Users can also perform advanced reporting and analytics, publish custom actions, create public groups and more.

About Log Shipping SQL Server

Log Shipping:-


Log shipping is the process of automating the backup of a database and transaction log files on a primary (production) database server and then restoring them onto a standby server. This technique is supported by Microsoft SQL Server, 4D Server, MySQL, and PostgreSQL.

Similar to replication, the primary purpose of log shipping is to increase database availability by maintaining a backup server that can replace production server quickly. Other databases such as Adaptive Server Enterprise and Oracle Database support the technique but require the Database Administrator to write code or scripts to perform the work.

Although the actual failover mechanism in log shipping is manual, this implementation is often chosen due to its low cost in human and server resources, and ease of implementation. As a comparison, SQL server clusters enable automatic failover, but at the expense of much higher storage costs. Compared to database replication, log shipping does not provide as much in terms of reporting capabilities, but also backs up system tables along with data tables, and locks standby server from users' modifications.

A replicated server can be modified (e.g. views) and therefore is not suitable for failover purposes.

About Log Shipping (SQL Server):-


SQL Server Log shipping allows you to automatically send transaction log backups from a primary database on a primary server instance to one or more secondary databases on separate secondary server instances. The transaction log backups are applied to each of the secondary databases individually. An optional third server instance, known as the monitor server, records the history and status of backup and restore operations and, optionally, raises alerts if these operations fail to occur as scheduled.

-- Benefits
-- Terms and Definitions
-- Log Shipping Overview
-- Interoperability
-- Related Tasks
-- Benefits

Provides a disaster-recovery solution for a single primary database and one or more secondary databases, each on a separate instance of SQL Server.

Supports limited read-only access to secondary databases (during the interval between restore jobs).
Allows a user-specified delay between when the primary server backs up the log of the primary database and when the secondary servers must restore (apply) the log backup. A longer delay can be useful, for example, if data is accidentally changed on the primary database. If the accidental change is noticed quickly, a delay can let you retrieve still unchanged data from a secondary database before the change is reflected there.

Terms and Definitions

Primary server:-

The instance of SQL Server that is your production server.

Primary database:-

The database on the primary server that you want to back up to another server. All administration of the log shipping configuration through SQL Server Management Studio is performed from the
primary database.

Secondary server:-

The instance of SQL Server where you want to keep a warm standby copy of your primary database.
secondary database

The warm standby copy of the primary database. The secondary database may be in either the RECOVERING state or the STANDBY state, which leaves the database available for limited read-only access.

Monitor server:-

An optional instance of SQL Server that tracks all of the details of log shipping, including:
When the transaction log on the primary database was last backed up.
When the secondary servers last copied and restored the backup files.
Information about any backup failure alerts.

Important

Once the monitor server has been configured, it cannot be changed without removing log shipping first.

Backup job

A SQL Server Agent job that performs the backup operation, logs history to the local server and the monitor server, and deletes old backup files and history information. When log shipping is enabled, the job category "Log Shipping Backup" is created on the primary server instance.

Copy job

A SQL Server Agent job that copies the backup files from the primary server to a configurable destination on the secondary server and logs history on the secondary server and the monitor server. When log shipping is enabled on a database, the job category "Log Shipping Copy" is created on each secondary server in a log shipping configuration.

Restore job:-

A SQL Server Agent job that restores the copied backup files to the secondary databases. It logs history on the local server and the monitor server, and deletes old files and old history information. When log shipping is enabled on a database, the job category "Log Shipping Restore" is created on the secondary server instance.

Alert job

A SQL Server Agent job that raises alerts for primary and secondary databases when a backup or restore operation does not complete successfully within a specified threshold. When log shipping is enabled on a database, job category "Log Shipping Alert" is created on the monitor server instance.

Tips:-

For each alert, you need to specify an alert number. Also, be sure to configure the alert to notify an operator when an alert is raised.

Log Shipping Overview
Log shipping consists of three operations:
Back up the transaction log at the primary server instance.
Copy the transaction log file to the secondary server instance.
Restore the log backup on the secondary server instance.

The log can be shipped to multiple secondary server instances. In such cases, operations 2 and 3 are duplicated for each secondary server instance.

A log shipping configuration does not automatically fail over from the primary server to the secondary server. If the primary database becomes unavailable, any of the secondary databases can be brought online manually.

You can use a secondary database for reporting purposes.
In addition, you can configure alerts for your log shipping configuration.

A Typical Log Shipping Configuration

The following figure shows a log shipping configuration with the primary server instance, three secondary server instances, and a monitor server instance. The figure illustrates the steps performed by backup, copy, and restorejobs, as follows:

The primary server instance runs the backup job to back up the transaction log on the primary database. This server instance then places the log backup into a primary log-backup file, which it sends to the backup folder. In this figure, the backup folder is on a shared directory—the backup share.

Each of the three secondary server instances runs its own copy job to copy the primary log-backup file to its own local destination folder.

Each secondary server instance runs its own restore job to restore the log backup from the local destination folder onto the local secondary database.

The primary and secondary server instances send their own history and status to the monitor server instance.

What is “incarnation” in Oracle database

Incarnation

A separate version of a database. The incarnation of the database changes when you open it with the RESETLOGS option, but you can recover backups from a prior incarnation so long as the necessary redo is available.

Database Incarnation History

Incarnation 1 of the database starts at SCN 1 and continues through SCN 1000 to SCN 2000. Suppose that at SCN 2000 in incarnation 1, you perform a point-in-time recovery back to SCN 1000, and then open the database with the RESETLOGS option. Incarnation 2 now begins at SCN 1000 and continues to SCN 3000. In this example, incarnation 1 is the parent of incarnation 2.

Suppose that at SCN 3000 in incarnation 2, you perform a point-in-time recovery to SCN 2000 and open the database with the RESETLOGS option. In this case, incarnation 2 is the parent of incarnation 3. Incarnation 1 is an ancestor of incarnation 3.

When DBPITR or Flashback Database has occurred in database, an SCN can refer to more than one point in time, depending on which incarnation is current. For example, SCN 1500 in Figure 13-1 could refer to an SCN in incarnation 1 or 2.

You can use the RESET DATABASE TO INCARNATION command to specify that SCNs are to be interpreted in the frame of reference of a specific database incarnation. The RESET DATABASE TO INCARNATION command is required when you use FLASHBACK, RESTORE, or RECOVER to return to an SCN in a noncurrent database incarnation. However, RMAN executes the RESET DATABASE TO INCARNATION command implicitly with Flashback

Let's say you start with an Oracle database called PROD, replicated to a physical standby called STNDBY. You refresh your development environment by taking a copy of STNDBY via RMAN† and calling it MASTER. You open MASTER read-write, to do some actions (e.g. deleting sensitive user data) and then copy that for your developers, called DEV1, DEV2 etc. One of your developers wants to do some experiments, so he further clones DEV1 into DEV1A. So there are now many versions of our database


------    --------      --------       ------      ------- 
|PROD| -> |STNDBY| -*-> |MASTER|  -*-> |DEV1| -*-> |DEV1A|
------    --------      --------       ------      -------


The * indicates points at which you have done OPEN RESETLOGS or created a new controlfile. This means a new incarnation of the database. You could not apply redo logs "backwards" in this chain, e.g. even if you shut down PROD (so its SCN does not increment) before creating MASTER, you could not make changes in a downstream database, for example DEV1, then apply the redo logs back to PROD even tho' they are the "same" DBFs - the incarnation has been incremented.


This is what it means by recover backups from a prior incarnation


Well, the incarnation is an especific break point in the life time of the database. To be clear you may look at the database life cycle as it starts its creation through its full and redo log backups, imagine this as a time line, now after several backups you need to go back in time and restore the whole database to an specific point in time or SCN, once you do this you must open the database with resetlogs which creates a new encarnation of the database because the backup chain it used to have from the point of the new incarnation to the point in time where you decided to restore the database, cannot be use any more, this is because new operations are been logged to the redo logs once you open it with reset logs, so a new parallel time line of backups must be generated starting from the incarnation point in time.

How to Lose Belly Fat Fast With Amazing Spiced Ayurvedic Tea

Ingredients Needed to Make The All- Spice Tea to Burn Your Belly Fat Fast

• 1 tablespoon of Carom seeds (Ajwain)
• 1 tablespoon of Cumin seeds (Jeera)
• 1 tablespoon of Fennel seeds (Saunf)
• 1 tablespoon Coriander seeds
• 2 small sticks of Cinnamon
• 10 Cloves
• 2 small pieces of Ginger
• 8-10 black Peppercorns
• 1 litre of water

How to Make All Spice Ayurvedic Tea for Reducing Tummy Fat?

• Take a large pot and place it on a high flame
• Add the water to the pot and let it come to a boil.
• Take a mortar and pestle and coarsely grind and break the spices like cinnamon sticks, black peppercorns and Coriander. Crush the ginger to break it down.
• Doing this will extract maximum flavours out of the spices.
• Add the spices to the boiling water and cover with a lid. Let the spices infuse the flavour and goodness into the water.
• After 10 minutes, turn the gas off and let the water cool down and come down to room temperature.
• Take a large jug or flask and strain out the spices out of the water and store the water in this flask.
• Your All-Spice Ayurvedic Tea is ready!

What are The Benefits of The All-Spice Ayurvedic Tea?

• The heat element in all of the ingredients, leads to speeding up of the metabolism, thereby helping you on how to burn belly fat fast.
• Loaded with anti-microbial properties, this Tea boosts the immunity of the body.
• Burns and flushes out toxins from the body.
• Purifies blood and relieves inflammation.
• Warms up blood circulation.
• Cleanses urinary tract.

When and How Much All-Spice Ayurvedic Tea Should You Drink?

Standing through the tough test of time, you can have this tea at any point in time of the day. Being caffeine free and good for your health, this All-Spice Ayurvedic Tea can be consumed in between meals too. But it is seen that best results from this Tea can be achieved when it comes to losing fat around the waist if had the first thing in the morning and the last thing in the night. 1- 2 cups can be had in a day.

Moderation is commonly advised for all, especially for women, as these spices have a tendency to add heat to the body which may lead to menstrual complications in women.

It is very essential, to take care of one’s health and thus s that houses a number of deadly diseases are crucial. Adapt this All Spice Ayurvedic Tea and live a life abundantly blessed with good health.

This All- Spice Ayurvedic Tea helps you to burn tummy fat and lead a good life.

Wish to have a good life ad want to know how to lose belly fat fast? Then try out our recommended All-Spice Ayurvedic Tea and let us know your experience